On Technical Debt and Mergers and Acquisitions

by

Mergers and acquisitions can always result in some sort of unplanned issue emerging – whether it be about competition or integrating two disparate IT or HR systems. For this reason, the SEC has strict rules on the information that the acquiring and target company must provide to stockholders of public companies. This is done so that they can be fully informed on whether to vote for or against a potential acquisition. This information is usually centered on financial, operational, and competitive disclosure – but considering what we know about technical debt, shouldn’t it also be part of the dissemination of information before a potential merger and acquisition?

In a great post from CAST’s On Quality blog this question is answered in detail.

Software assets are continually becoming part of the valuation of company, and because of this any buyer should insist on technical debt being part of the assessment process. After the completion of the assessment, the monetized measure of technical debt (which can be done through the CAST Application Intelligence Platform) should be deducted from the acquisition price or be managed to the buyer’s standard of satisfaction. It should also be noted that if we are placing importance on technical debt in code during the process of the acquiring an organization, then the buyer should understand the implications of technical debt. This debt can result in some serious issues like application crashes, degradation of hardware and software performance, and an increase in software risk through the potential corruption of critical data.

Improving and measuring software quality can be an extremely complex process (especially in multi platform, language, and sourced applications) but is directly tied to the identification and quantification of technical debt. It’s always been a bit of a problem that investing in ways to improve software quality does not have seemingly have instant ROI – but it is important to understand that investing in quality pays for itself many times over. If you’re working on high quality software, it makes it easier for developers to modify code to meet pressing needs more quickly than if they were working on code riddled with bugs.

While it is the case that the less technical debt you have the better your code quality will be, it is not feasible to entirely eliminate it. When both speed and quality are critical factors to the success of any organization, being able to measure the structural quality of applications and to make sure that technical debt is at manageable levels could mean the difference between a smooth merger and one marred with complications.

Technical debt is a significant component in the day to day operations of any organization IT department (and to the organization as a whole) – because if it is left unmanaged it can be extremely harmful to the productivity and success of your applications. But it carries particular significance in relation to mergers and acquisitions. With technology becoming a more significant value driver during the merger and acquisition process, it is logical to assume that we should also start to assess technical debt with more scrutiny.

In a recent webinar from CAST in partnership with the Boston Consulting Group it was pointed out that 2015 was a landmark year for the number of mergers and acquisitions. This increased number of M&As signifies the need to more openly discuss the complexities of technology integration during the M&A process. The early identification of software risk in these scenarios helps manage and increase the probability of M&A success.

This means undergoing high level analysis of relevant application portfolios – adequately measuring application portfolios that will be most impacted by M&A activity – will help to enable communication between technology and business stakeholders to find synergies between the portfolios. The availability of objective measures during the M&A process will ultimately enable stakeholders to drive the value up – and that is an highly important goal to achieve.

Filed in: Technical Debt
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|