If you don’t think a company’s tech matters, think again. This is the single biggest risk and hidden cost when it comes to making your day one target and realizing the cost savings you were banking on with the acquisition.
It is refreshing to see an article in this week’s Wall Street Journal looking at the hidden traps found in what we call in the industry: legacy software. It isn’t so much the software itself, but the bailing wire and duct-tape that has been added over the years to enhance the original system. Think of the changing business requirements and pivots over the years from an established company. The technical debt of deferred maintenance that everyone ends up paying for eventually whether it is your home, or the data center.
This is also one of the reasons why some much newer, software-based companies are eating the lunch of the more established players: they don’t have the issues the older plays have by trying to keep up with the times.
How can you tell this is an issue? Just like buying a house, this is where you’d bring in an inspector. Failing that, there are a few things to keep in mind, and is how I’ve looked at various systems in the past:
- For any system, look at the inputs and the outputs.
- Look at the dependencies.
- Look at the way the software is built and maintained.
- Look at the quality of the documentation.
Look at the inputs and outputs
Data is the lifeblood of an organization, and the flow of that data will tell you which systems are involved. You don’t have to go to the code level, but even looking at the sequence of events will help expose some of the technical debt and build out the next piece: the dependencies.
Look at the dependencies
The dependencies tell you how the software relates to everything else. What is custom to the company and what is outsourced through various cloud-based vendors, or on-prem. More importantly, this will tell you what other surprised you should be wary of such as third-party software or possible risks where a critical component could take the company down.
Look at the way the software is built and maintained
This indicator goes towards software quality as well as the build/release process that the company has to ensure software quality and reliable deployments. This also indicates how much technical debt is in place, or being introduced. The maintenance side would look at things like the number and types of outages, who’s involved in the resolution as well as how they are handled and if there is a post-mortem/next steps towards addressing it. It also goes to show the quality of who creates and maintains the software powering the business.
Look at the quality of the documentation
The state of the documentation indicates how well the ecosystem is maintained as well as the training of the staff on what the software does, who’s responsible, and how it can be fixed. In many organizations, the documentation is usually written once when the software is developed, or in the beginning to flesh out some of the designs, but it is rarely kept up to date to reflect the current state of the ecosystem resulting in its own form of rot. It is, in fact, worse than this, inaccurate documentation is worse than no documentation because it can result in a false sense of security in how the system behaves. This is one of the reasons why the software development world has the adage about the source code being the documentation: the documentation is never executed.
In summary, software has become core to many companies, and should not be surprising that the cost to clean up the cut corners of delivering features over the years to be hitting $1.5 trillion from the US alone. The question then becomes when and where this should be paid, and is this not only acceptable, but budgeted into the close and accounted for as a part of the integration activity after the deal closes.
If you would like an inspector to help ascertain the state of the tech stack with a potential company, we can help! Reach out for an initial consult, and we can take it from there.