Dominant Designs in Software Engineering: How to Recognize Their Value in an Acquisition
As an M&A IT consultant, my job is to ensure that every acquisition (or merger) I handle is successful. This becomes especially tricky when the transaction involves varying degrees of technology maturity between firms..
One way to help build integration plans is to look at both companies’ use of dominant designs (or lack thereof). This is especially important when searching for a target. And while it’s true that dominant designs may not always be the best — they’re much more likely to work in the market.
But here’s the thing — a company that uses a serverless architecture or follows cloud-native design patterns isn’t guaranteed to add value to the parent company. In fact, it can erode value as well. So how can one recognize the true value of dominant design in an acquisition?
Understanding the Technology in Relation to the Company
All four of the dominant designs discussed in this series solve modern problems of software development by creating more scalable, cost-effective, and resilient applications. But there are different trade-offs as well.
The key to choosing the right dominant design for your product and accurately estimating the deal value/impact during an acquisition is to know what your biggest problems are and what investments you are willing to make to your organization.
Take, for instance, a company following a monolithic architecture and losing out due to increasing Time-to-Market — a problem it tries to solve by acquiring new blood in the form of a DevOps startup full of rockstar DevOps engineers.
Yet the acquisition ultimately fails because of the existing monolithic environment when the DevOps engineers are used to deploying microservices.
This might seem like a rare failure caused by a huge oversight and inadequate due diligence. However, similar cases are more frequent than they should be and can be avoided through a better understanding of dominant designs as well as by taking proactive measures.
Here are 5 proactive measures that help in recognizing the true value of a particular technology during an acquisition:
- Do a Full Proprietary Software Review
A proprietary software review is part of the due diligence but isn’t always fully carried out by the acquirer. Proprietary software (as opposed to off-the-shelf software) is often the key driver behind technological acquisitions and if this is the case, a full proprietary software review to evaluate the true performance of the package is in order.
One of the main purposes of the software review is to ascertain the compatibility and scalability of the proprietary software with the parent company’s IT platform and to grade how well the software might scale to meet the acquirer’s needs.
One thing that the acquirers must look out for is poor scalability and compatibility of proprietary software with other platforms. Often the target company will only focus on optimizing the proprietary software for their own platform and aren’t heavily invested in making it very scalable (especially if the end goal of the target company was to eventually get acquired). This increases the risk of the proprietary software not performing up the expectations and ultimately paying an inflated transaction price.
2. Ensure Modularity and Correct Implementation of Cloud-native Technologies
Modularity in cloud-native technologies refers to their ability to be modified with ease. This is a key requirement in acquisitions to ensure that the software and platform can be modified during the migration/integration period. There are various characteristics of cloud-native technologies that limit this modularity when changing platforms.
For instance, when the technology in question is serverless, enterprises must take into consideration the cost of vendor-lock (if the target company is using a different cloud services provider than the acquirer).
3. Find Single Points of Failure
A single point of failure (SPOF) is an element in the infrastructure that when fails, takes down the entire system with it. The presence of SPOFs is greatly reduced with cloud-native technologies like microservices even microservices can have single points of failure. And more importantly, an increasing number of mergers and acquisitions are between tech and non-tech companies which means the possibility of one entity having a monolithic architecture is very high.
To avoid this the system failing after an acquisition, developers and executives must focus on finding and eliminating these single points of failure before data migration and integration. SPOFs can exist in cloud-environments, which is why it’s so important to do a thorough platform review to identify and remediate these concerns.
4. Determine the Golden Ratio
The ratio between retiring technical debt, net new development, and technical triage isn’t actually called the Golden Ratio but it’s certainly important enough to be called so — here’s what it entails.
Some amount of technical debt is inherent in nearly every software that’s regularly updated and reworked. That said, the amount of technical debt should* be around the 20 percent mark. And more importantly, the process of retiring technical debt should be continuous since all software decays over time as newer methods and techniques are always invented to improve performance, scalability, and reliability.
Net new development should* be in the 60%-70% range and the remaining time should be spent on fixing bugs and severe issues. If more time is spent on fixing bugs and glitches, there may be bigger underlying problems that require your attention.
Note* — The amount of time spent on retiring technical debt, new development, and fixing bugs will be highly dependent on the target, its industry, and the technical stack but is generally close to the 20:60:20 ratio I’ve mentioned here.
5. Examine Target’s Roadmaps for Future Growth (if any)
Scalability is at the center of any cloud-native technology and chances are, it is at the center of your investment thesis as well. However, not all companies use cloud-native technologies for future scalability nor do they implement it correctly.
One way of improving the due diligence process is to look at the target company’s roadmap for future growth (in terms of product engineering). The roadmap should outline plans for scaling up involved technologies and dominant designs and is also a healthy indicator of the target company’s dedication to building a scalable platform.
Lack of a roadmap is not a great sign and such a case would require greater scrutiny to ensure that the target company implemented cloud-native technologies properly.
Wrapping up…
And with this, the 5-part series on Dominant Designs in Software Engineering comes to end. The series was meant to educate business executives on the basics of the current dominant designs in the industry, why they are important, and how to recognize their value in an acquisition.
You can read the previous installments by clicking on the following links: microservices architecture, serverless computing, DevOps, and cloud-native design patterns.
