This summer Southwest Airlines underwent various technical failures that led to the cancellation of 2,300 flights over the span of four days. This cost the airline approximately $54 million. Not much time had passed when a power loss at Delta led to a massive outage and British Airways experienced difficulties when their check-in systems failed. The purpose of outlining these failures is not to pick on the airlines, but to highlight that you don't want to be in the headlines for reasons like the ones outlined above.
These sort of avoidable disasters are partly due to aging systems that have become brittle due to budget constraints and deferred investments. Operational meltdowns like the ones we mentioned can also be attributed to a massive build up of technical debt. Identifying technical debt can be difficult enough, but being able to communicate it to business stakeholders in terms they can understand is an additional challenge. If you look at an organization like Citi Bank, where there are 20 data centres, 50,000 servers, 350,000 laptops and desktops, 20,000 applications, and 12 billion transactions per month - how to you begin to comprehend this amount of complexity let alone explain it someone else?
Non-technical people often don't understand the complexities associated with a given technology, and an argument can be made that they shouldn't have to, but they should understand technical debt and the need to pay it back. This means that those working directly with technical debt also need to be able to communicate technical debt and its consequences adequately. The issue is that technical debt is often not immediately visible.
One of the many causes of technical debt is the rise of bi-modal IT - by extending IT to support new business models in a given company's digital transformation, IT has began to split between fast and slow tracks. While the fast track is innovative and responsive to change, but the long term issues that haven't been thought through in the search for innovation are passed over to the operations team. But it can't be forgotten that technical debt must be paid back.
Another cause of technical debt is the need to get to market as quick as possible, whether it is an actual need or not. This will lead to further short cuts and the creation of more liabilities.
Technical debt is therefore the cost that arises due to working to complete unfinished tasks that arose from a drive to be agile and innovative, or from lack of funding. And while most technical debt is not immediately visible, waiting until it is can be too late to fix it appropriately. When technical debt goes unpaid it compounds. Every time you try to enhance a feature without fixing those underlying issues from technical debt you will be adding inefficiencies, complexity, and cost to a project. Ultimately, you can end up with consequences just as severe as the technical failure we described at the start of this post.
The first step to going about paying back technical debt is by making it visible and recording it in the repository. Then making a report with budget priorities on how to resolve the debt identified and recorded.
To read the full post visit here.
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.