Technical debt: Running the car with parking brakes on

This is the fourth article in the series of nine articles on Digital Enterprise. In the first article, we talked about business model in terms of expanding digital footprint of the enterprise. In the second article, we talked about reassuring our eco-system and building trust explicitly. In the third article, we talked about the importance of experience in digital success. Now, let’s move towards the technology aspects.

Technical Debt is a very popular concept as a braking factor which can hamper the acceleration of your digital ambitions. In fact, it is one of the biggest technological factors that can hold back your long-term digital transformation. So, let’s understand how to address technical debt from a management science point of view.

Technical Debt is created by insufficient investment in keeping your systems updated. It’s like building a good road and not maintaining it, or not repaving it. This road, full of potholes, cannot support a car to go faster. The car is your digital transformation, and the pothole is the technical debt.

Technical Debt is the result of insufficient investment in upkeep of what you have already invested in. It's like your municipal corporation building great road, but not spending enough in its upkeep. Or sometimes not building a new or alternate road.

We have to look at our technology, architecture and landscape from a future point of view.

What you have today, was built ten years back. It obviously did not factor in your more recent digital ambitions. In a way, your current foundation is of a five-story building whereas you, as a digital enterprise, need the foundation of a fifty-story building - TODAY.

Can you build a fifty-story building on the foundation laid for a five-story building?

This provides the best and strongest argument for investment in technology to reduce your technical debt.

When I first took over as the CIO, we had the same issue – the systems were in their n-x, n-y states. We conceptualized a Technology Upkeep Index (pronounced to-ee) as a collective aggregated measure of how many major versions behind are we from the latest available version of technology. We leveraged it for hardware, applications, software, security etc. Our target was to be always one major version behind the latest one so that you avoid the bugs inherent in the latest version.

Design your own Technology Upkeep Index (TUI) as a KPI to measure the current reality first

Getting the Investments

The next is how to gather money for technical debt. In my tenure, we kept a backlog of business demands in terms of the projects everyone wanted IT to undertake. Many of them were about building apps for the enterprise, and certain new capabilities which are inherently bound to digital. We took a portfolio view of it. We had a hypothesis that when we upgrade our applications to the latest version, the digital capabilities should come inherently as part of that upgrade. We were able to validate this hypothesis to improve, and then our business case became a collective business case of not only the upgrade but also some of the digital capabilities that people wanted on top of our enterprise applications.

When you upgrade your application to latest version, you automatically benefit from the digital capabilities your product partner has built into it.

For example, you don’t have to build an employee app if you are on the latest version of your HR application. In another application, your upgraded version may have an HTML5 interface, which means you don’t need to develop a mobile app – the application will render perfectly on any mobile device of any form factor. Or, the upgrade may support APIs which will reduce your investment in API infrastructure.

Technology after technology, we were able to validate this hypothesis and it made our case stronger for upgrades while at the same time, keeping our technology landscape simple enough – by not building a lot of apps.

Playing the long game

We know that the current business world tenures and careers are short which leads to motivation of a digital showcase in a quarter or two; or having an annual scorecard of digital initiatives – the visible ones.

Building the foundation of a fifty-story building where you can’t see anything until a few years later is not really an attractive proposition. But mind you, the tenures may be a few years long but the careers are decades long and your credentials as a digital transformer can be very strong if you decide to play the long game, and set up strong foundation of digital enterprise for your organization. It may mean saying no to many short-term initiatives, it may mean building a foundation first before building a show flat, but remember, you will be doing a big justice to your career and your personal brand as well as your enterprise.

Play the Long Game. Build your personal brand as a fundamental foundation builder of digital transformation, and not playing to the galleries for claps

Case Study: When we initiated digital transformation, we were on a power-UNIX platform. We had big cloud ambitions but we figured that we had to be on LINUX to be ready for the cloud. We planned and executed a complete infrastructure migration from AIX to LINUX (A2L), to migrate majority of our landscape to LINUX which would give us the capability to work seamlessly with the cloud. This strategy enabled us to move all our non-production systems to cloud while keeping our production systems in house and still having the fidelity of testing across multiple environments.

By-products of reducing Technical Debt: IT Team Motivation

Creating an agenda for reducing technical debt is something that can spur and motivate your team members who built that five-story building. You can challenge them to rework the foundation. It can be relatively easy because they are the ones who set up those foundations. For all you know, they would have struggled to convince the management in upgrading these systems.

You can rally the entire IT organization behind you, and seek credibility as well as their trust by addressing the foundations first, before going for the attractive building.

Risk

I think the last argument for addressing technical debt is risk. We see cyber security risks growing larger by the day, and one way to convince your management to invest in getting rid of the technical debt can be cyber security and technology risk itself. Technology becoming more and more critical for the business, cyber security has become a reputational risk now. By creating an agenda of reducing technical debt with technology risk and cyber security at the center of it, can get you a huge traction with your senior management.

Technical debt is your parking brake - don’t drive your Digital Ambition car with it. Find your KPI like TUI; Leverage Upgrades to deliver new capabilities (not just upkeep). Play the long game; motivate your team to modernize what they built; and manage risk actively by investing in upgrades.

Please leave your comments here, or in the author’s LinkedIn Posts. In the fifth edition of this series of articles, we’ll talk about architecture. You’ve got to create some sort of architecture governance to break this chain as a challenge to your digital transformation.

The article has been written by Jagdish Belwal, Founder and CEO, Jagdish Belwal Advisory