Transformation, Technical Debt and Toxicity... Episode 4

Episode 4 - Pricing a technology estate

My series of articles on technology transformation (episode 1) was supposed to be a set of 3. Much like Douglas Adams, I have decided to make it a trilogy in 4 parts??, as it was mentioned to me that sometimes you acquire technical debt (episode 2) and cultural toxicity (episode 3) through a rushed company acquisition or merger.

While this extra technical debt is in itself not an issue if accurately quantified and costed before an acquisition, unfortunately this is usually not the case. Once the ink dries on the deal, headaches for both legacy technology departments begin. Depending on the level of technical debt revealed post-merger, this can take years to remediate and adds huge unaccounted costs to integrating organisations.

An initial culture clash is inevitable when 2 disparate organisations merge or one acquires the other. As that would be the topic of at least one more article, I'll only focus on technology decision inputs that should be part of an M&A process. Suffice to say with any merging of companies there will an initial "them and us" that needs to be removed immediately. This was discussed in episode 3.

I will also use the terms "Merger" and "Acquisition" interchangeably for simplicity even though they have very different power dynamics in the resulting combined organisation.

Technical debt revealed post-merger, at its worst it can significantly undermine the anticipated benefits of an acquisition and greatly reduce expected return on investment for the purchasing organisation. As such, it is vital that a company have a realistic knowledge what they are acquiring (in terms of technology) before making a decision. This is high stakes caveat emptor[1], and ignorance is not a defence?on your balance sheet if in hindsight, you have bought a lemon. Again, this article is dealing with companies that have a high level to technology, SaaS service or software development capability in their business model.

What are you really buying ?

Before any contracts are signed when pursuing a merger with a company, the potential purchasing business should be able to articulate clearly to their board what is the primary reason for contemplating an acquisition in the first place.

• Is it to increase market share or break into new markets (increase your service offering and by extension your investor ROI / EBITDA)
• Is it to get a leap in technology assets from what you have currently (an intellectual property play to reap significant competitive advantage in the near future)
• Is it part of a wider industry consolidation play (our competitors are doing it and gobbling up market share)
• A mixture of all of the above

"A mixture of all of the above" should be a warning flag as by its nature lacks clear quantifiable benefits and is more based on Hope/Hype than having a clear primary benefit of a potential acquisition. That being said, any merger should be possible if the benefits and risks are accurately quantified. The "mixture" motivation rarely achieves this rational analysis however.

If your wider industry competitors are themselves engaged in rounds of mergers and consolidation, there is often a fear of being left behind. Companies should not succumb to a "me too" management strategy. It is wise to not rush to find potential acquisitions just because it is in fashion. Make sure any potential targets are indeed of strategic benefit to your organisation and pass the rational cost/benefit analysis test. If there is a lot of merger activity in a particular sector it could of course mean that there are both valid reasons for sector consolidation and more companies willing to enter discussions about mergers and acquisitions. It may be a good time to consider acquisitions but not a reason to omit rigorous dispassionate cost benefit analysis before signing a deal.

A "Technology assets" gambit is less of an issue in the context of this article. If you are seeking to purchase a company for its intellectual property (technology), the focus of your due diligence will be in accurately assessing and costing out the technology estate. The chances of unknown technical debt creeping in with this type of acquisition is far less than the other business drivers for a merger. Technologists for the acquiring company should be front and centre in all discovery efforts.

Finally, we come to the most usual motivation for merging or acquiring a company; to increase market share or enter new markets. This scenario unfortunately, is the where a lot of inadvertent technical debt creeps in, particularly if it is a pure market share increase play i.e. a growth by acquisition strategy. Sometimes so much unaccounted technical debt is accrued that is leads to serious buyer's remorse after executing the deal. Of course, to clear this debt means having to deal with a painful, un-costed transformation to reap the original benefits that made the merger attractive in the first place.

Growth by acquisition

If you have decided that a potential company is a good fit for your organisation's strategy of market share increase, that compliments your current market share, then you have a choice to make. You are buying a client book, not their technology stack. Even if you think you are buying a technology stack you are not buying a usable technology stack. Any technology used to host the prospective client book you are buying should be priced at zero. In fact, it should be considered less than zero as there will be system rationalisation, data migrations and development to be done post-merger to monetise this acquired client book efficiently. You already have systems that perform the same function and now you have 2 of them (but with greater market share). The candidate company's IT estate is a liability in the acquisition deal financials.

If you are buying a company for its client book, to increase your own, their current technology is worth less than zero.

This is a harsh reality to face, and a negative valuation of an IT estate grates against the technologist in me. Yes, there may be good tech or well architected systems in the acquired company but that is not the reason for the purchase. Some elements may live on (or even replace the acquiring company's incumbent systems) but only after a large transformation. The valuation should still be negative, but the better the systems, the less negative the number will be. Having now acquired a duplication of systems with similar functionality, they have to go the way of all two-headed creatures; one system has to be decommissioned rapidly. The negative valuation of the technology estate could be thought of as the cost of funding the invariable transformation effort required to slay your now two-headed technology beast and achieve efficient operation of your increased market share.

Sizing up the beast(s)

Deciding which of the duplicated systems to replace is a technology decision full of ideology, bias and almost religious fervour. This bake off between which of the two systems will be preserved will enflame a lot of technologist's passions within any new merged organisation. No technologists likes being told their child is ugly or no longer fit for purpose. It is important that systems from both organisations are compared to each other, a true bake off. It should not be assumed that the acquiring company's systems are the ones that will remain. Remember you are aiming to increasing the size of a client book (market share) efficiently, not to double the footprint of the resulting tech estate.

There are a few steps that can be taken before a merger to ensure you know the size of any technology overlap or unaccounted for technical debt. These discovery efforts should be considered as reasonable due diligence by any prospective buyer of an organisation and a refusal to do so by the candidate company should in itself raise alarms.

1 - CMDB A configuration management database is a key component in infrastructure management (both on-prem and cloud based). Its existence hints that the company takes operational excellence seriously. Its absence, or a set of visio diagrams in its place, should be a worry. A potential acquiring company should ask for access to get an accurate picture of the size, vintage and tech stack they are getting alongside the client book. This needs to be compared dispassionately with what they currently have. This will reveal technical debt from the operating system downwards. Having to refresh an entire data centre to maintain the systems you just acquired is not where you want to be.

2 - SDLC process Gaining an insight into a candidate company's software deployment processes not only reveals the tech stack used (and allows you to estimate how compatible any system is with your incumbent ones); but also, how disciplined the tech culture is around stability & performance as well as delivery. It will give you an insight on any technical debt from the operating system upwards and flag any cultural clash that may occur post-merger. It will also tell you what sort of IT operations headache you might be inheriting. Having a radically different tech stack & SDLC for the platform hosting the client book you are acquiring implies a difficult integration & transformation ahead. Having a very different attitude towards service operations is a leading indicator of future culture clash.

It is perfectly acceptable to have a number of different programming languages, databases, cloud providers etc. in an enterprise tech estate, but in the long term these should be rationalised and software refactored to keep it to a minimum for enterprise-wide cost efficiencies to be realised. It also allows future growth by making the technical estate sustainable for the resultant merged organisation's actual technical capability.

Everything should be made as simple as possible, but no simpler! - Albert Einstein (sort of [2])

Remember, for the buying organisation, in growth by acquisition, we are assuming you are already in this market and you have systems providing the same functionality as it is the client book you are buying. To refresh an infrastructure and software stack is a fairly mechanical process but realistic financial estimates and timelines of it should be obtained to see how negative the costing of the technical estate transformation required should be.

3 - Burn Rate Probably already factored into acquisition negotiations, but the total cost of ownership of the tech estate, its current client size and its ability to handle current business volumes should be a factor in any merger discussions. Payroll costs, infrastructure costs, cloud costs and software licensing should all be readily available for an acquiring company to examine. Just look at the invoices. Are the costs to run the client book you are seeking in line with the usual industry overheads? This again will feed into the pricing of the technical estate.

4 - Security While CMDB and SDLC investigations gets you information on the state of technical debt both sides of the operating system, a security scan will also investigate the network and application layers of the company you are interested in. A well scoped penetration test, performed by a reputable security company should be a standard discovery tool requested by any company thinking of acquiring another. Refusal is a warning sign. Penetration tests reveal how historical software development occurred, how seriously a company handles client data (you are buying their client book after all), how technical debt is being remediated and again gives an insight into the technical culture you may be acquiring. Refusal to allow a penetration test is again a clear warning sign that there is serious technical debt hidden in the company you are thinking of merging with.

In short if you are pursuing a growth by acquisition strategy in a market you are already operating in, an accurate costing of the technical debt you are also buying can be inferred by looking at the 4 elements discussed above. If not done correctly you will not only have to do an un-costed transformation; but during the transformation period you will have greatly increased your OPEX for this increase market share. Greatly increased OPEX will drag you EBITDA down and you have just baked in large inefficiencies into you newly merged organisations.

Growth by "bolt on"

If growing your company by acquiring organisations in new markets, the problem of system duplication does not occur. This bolt on acquisition however does not mean a merger is without technical debt or problems. There will still be an incumbent technology estate that hosts systems that service these markets, developers that build and maintain these platforms and a support organisation to service these new clients that arrive on your doorstep post-acquisition. All have to be merged into the acquiring company. The bolting on process costs.

As this is not without cost, and the tech overlap (of lack of it) with your current IT estate still needs to be examined.

If you are buying a company for a new client book/market, their current technology assets should be discounted against the costs of the future technical merger required.

Standardisation of programming languages, operating systems, databases and hosting providers (either on-prem or cloud providers) still has to be undertaken to achieve operational efficiency for the resulting organisation. This takes time and money. As such, the 4 discovery themes mentioned above should still be applied so you know from an IT perspective what you will have to deal with for possibly years to come.

In Summary

Any potential merger or acquisition with a large technical component will mean the addition of technical debt that was somebody else's problem until now. Forewarned is forearmed requiring accurate due diligence and discovery of the technical landscape should be priced into the financial terms of the deal before it is signed. Failure to do so will leave your technical organisation with problems lasting years that will only result in disappointment as to the original benefits of doing the merger in the first place. The only options are then to take the loss or do a large un-costed transformation and take the pain.

[1] Caveat emptor - It is a short form of?Caveat emptor, quia ignorare non debuit quod jus alienum emit?- Let a purchaser beware, for he ought not to be ignorant of the nature of the property which he is buying from another party.

[2] The "Simple as possible" Einstein mis-quote is an interpretation of what he actually said in a lecture in 1933 which was "It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience"