There’s no doubt about it: Transformative M&A can help you to accelerate the digital transformation of your company. I have shared a few considerations on such M&A strategy in this blogpost: Transformative M&A: The Fast Track for the Digital Transformation of your Company ?.
Unsurprisingly, in companies with a digital business model the key asset is a software product, a self-developed core application or/and the entire IT infrastructure for a SaaS business model. You should then put special attention on your IT due diligence. I’ll share some helpful considerations on performing a thorough IT Due Diligence, provide a few guidelines, raise a couple of key questions.
Performance behaviour of software code, frequency of bugs
You should be able to answer some basic questions without specialists: What’s the overall performance of the software? How many errors (bugs) do users report on a daily/on a weekly basis? What’s the share of Prio1 oder Prio2 bugs? How long does it take to fix the bugs (MTTR: Mean-Time-to-Resolution)? How intuitive is the handling of the software, how’s the UX/UI?
Take a look into the ticket system: This will provide answer to many of the above questions: How many bugs are registered? What’s the priority of the bugs? What’s the average processing time of the tickets. The number of bugs can be put in relation to the number of users and the age of the software (for “older” software products, the number of bugs should be close to zero, as the software should be mature).
The performance of a software is usually evaluated with load tests. What’s the behavior of the software, if large amounts of data are processed, and if there’s a high number of (simultaneous) user requests. As a rule of thumb, a software company will generally carry out such load tests as part of their QA. Take a glance at such test reports. If you have doubts, perform your own load tests.
Evaluation of the technology stack, evaluation of the quality of software code
Now, let’s go a step further and take a look “under the bonnet”. First, what’s the technology stack of the software? That is: Programming languages, frameworks, libraries which are used in a software product. Is this future-proof, do you have sufficient number of developers available to maintain and further develop the software? If an application is written in Delphi, then the software does not fulfill this criterion.
If your target company is a long-established software company, the software design of the key assets may data back a while. You will sooner or later have a discussion about Microservices versus Monolithic Architecture. Today, software is increasingly designed to be run in the cloud, we call this Native Cloud Application (NCA). Such (cloud-ready) Software is characterized by a software architecture based on microservices. In other words: The application is highly modularized, each module being a small service that run as separate process (with a database and storage of its own). These services communicate with each other via APIs. Since these microservices are independent of each other, they can run in distributed environments. In addition, each microservice can be written in its own programming language. Microservices allow for excellent scalability in a container infrastructure.
Microservice architectures is unknown to older software applications (which still make up the majority of running software). Often it is a monolithic architecture, i.e. different services are not decoupled from each other, but are strongly interlaced. This can be determined not least with the help of analysis tools. Relevant metrics: tangled design or nesting level.
Software design is more of an art than a science. And you shouldn’t take a black-and-white view of software design, monolithic design can by no means be judged as “bad”. It depends. If product development requires frequent changes to software applications with a “monolithic” architecture, then you should be concerned; because of the tangled design such adjustments will be expensive. However, if such a software component is mature and hardened (and adjustments are rare), the monolithic design can be an advantage: This will be very efficient and high-performance programming code, since there are no interfaces between services in an NCA.
However, how do you assess the quality of the software code itself? The first thing you should do: Check out how good is the documentation. Take a probe of the code: Is it easy to maintain? Is this “spaghetti” code? Are best practices for naming variables and constants followed?
There is, actually, a number of software quality metrics you could use. One example: Connascence. This metric quantifies – in simple terms – how much effort is required for adaptations of the software code; according to this metric this effort is estimated to be particularly high if an adaptation to an element A (function, line of code, etc.) also requires the adaptation of element B at the same time.
Organization and workflows in a development team
In the course of due diligence processes I had the opportunity to work together with very experienced developers / development managers; as a rule of thumb I can therefore say: Three to four hours of interview are sufficient to get an idea of the development process in a team. How do they apply methods such as Scrum, Kanban or often Scrumban. What are strengths and weaknesses? In some cases you will realize, that development teams have labelled their method as “Scrum”, but the reality tells you otherwise. For example, the role of the IT manager does not exist in Scrum (however, in many companies practicing Scrum, there is still an IT manager). And if there are too few full-stack developers, this is also inconsistent with the basic idea of Scrum.
You have to pay particular attention to the processes for quality assurance: What’s the level of test coverage, i.e. what share of requirements are actually subjected to testing? How is the release process for a software or a new feature documented? What percentage of testing is covered by test automation (e.g. with Selenium or Robot Framework), how many automated test cases have been implemented already?
You must also find out, whether the development process is (overly) dependent on one person (or even two). Basically it comes down to a single question: Which team member to do you need to take out in order to bring the development process to a halt? If so, how long does it take to ensure the knowledge transfer in order to minimize the dependency?
Further questions, that are related to the previous considerations: How long does a new employee need to become familiar with a software component before he can develop productively? What is the proportion of full-stack developers in the team?
Penetration Test, Security
It’s a no-brainer: Application security gets ever more important in software development (Compare also the blogpost: How-to-Guide to improve application security in Software Development). Especially for web-based applications (and cloud applications) special attention should be paid to this.
It should be standard practice for developers of a web application to hire an external company for penetration testing; for this purpose, appropriate risk reports/analyses should be submitted and the measures implemented in response to them.
Licences, OpenSource Software
I will conclude this blogpost with some considerations about licenses. This applies especially to OpenSource software, that has become indispensable in software development nowadays.
Basically, for the use of open source software, the following minimum requirements must be met: (a) The third party is informed of the use of the open source software and the name of the rights holder is given. (b) The license terms are included in the commercial software license/documentation (i.e.: disclosure and information obligations). You can easily verify this during the IT Due Diligence.
A specific challenge when using open source software or more precisely: several open source components is the so-called license compatibility. What is this about? – Actually, some Open Source licences allow the use only under certain conditions. Unfortunately, some Open Source licenses are not necessarily compatible with each other. Each Software Company that uses Open Source Software needs to ensure, that all licensing conditions are fulfilled without contradiction. In fact, this is anything but trivial.
Commercial Software has hundreds of thousands or even millions of Lines of Code (LOC). For sure, it is close to impossible to assess the use of OpenSource software by going through the coe line by line. That’s why so-called OSS scanners are used in large M&A transactions (and in case of justified doubt). Here’s some common tools: OSS Discovery Project (Open Source Tool under the Affero GNU Public License), Black Duck (a pioneer in OSS scanners, commercial tool) or Flexera (formerly: Palamida, commercial tool). These tools not only identify used Open Source, but also detect (possible) license incompatibilities..
