Technology Debt & the BRM

What is Technology Debt?  (And more importantly, why should you care?)

Over the past two years, I’ve seen the concept gain traction among IT leadership and CIO’s, who use it as a way to help justify IT investments to the business.  However, I am still waiting for BRM’s to utilise the concept of Technology Debt to full effectiveness.  I believe it can be a very powerful tool to use to communicate some very real risks and consequences for the IT choices business leaders are faced with.

The term ‘Technology Debt’ originally came from the world of software development (also known as design debt or code debt) and is a metaphor referring to “the eventual consequences of any system design, software architecture or software development within a codebase”.  It has since grown up with many in IT using it as a concept that covers all short-term IT decisions which have long-term business consequences – from skipping a software upgrade or continuing to use less sophisticated development techniques.  The problem is those decisions have consequences and are realised in outcomes including system outages, lengthy software maintenance cycles and high maintenance costs.  So, just like the financial debt we may take on in our personal lives, like a mortgage or car payment, it gathers interest and eventually needs to be paid back!

Here are the 7 hard truths of Technology Debt as they apply to the BRM – we’ll talk about how to use them to advantage in conversations with Business and IT next.

  1. Technology Debt is directly related to the overall efficiency of IT and therefore the overall quality of IT services delivered to the business.
  2. Technical Debt can further jeopardise business operations by undermining the stability and reliability of systems over time.
  3. Technical Debt will magnify the impact of a downturn in the economic cycle.
  4. Debt is a risk of increased cost or schedule of development on account of current development processes and its outcomes.
  5. Technology Debt has a real cost.  That cost is not fixed – it changes over time, so there is no real way to accurately estimate it.
  6. When debt becomes too high, it becomes an impediment to business agility.
  7. Sometimes what we consider to be “Assets” are really a liability, such as Data.  Are we undercounting the ‘debt’ that accrues with growing required obligations, i.e., maintenance & regulation?


What is the role of the BRM in exposing and reducing Technology Debt?

Look, every IT decision that has been made or will be made is going to have some level of debt – therefore, every organisation has a debt load they are carrying (especially if you’ve had decades of technology investment – so some are bigger than others).  For the BRM, the questions are:  How do we help the CIO and IT leaders manage this liability and how do we help the business better understand technology debt and therefore reduce risk by avoidance of accruing additional debt?

The reality is that if you work with an organisation which has built up significant Technology Debt, it reduces your ability to be an agent of change.  In many cases I’ve seen, it makes the areas most BRM’s really love – introducing innovation – monumentally difficult, if not impossible.  High levels of debt hamper an organisation’s ability to innovate, grow and change because it sucks up all the resources available to manage the debt, rather than for things like implementing new technologies.  If your business leaders are committed to growth, then they need to also be aware of and committed to paying down the debt and having the governance in place to keep it in check.  As a BRM, using Technology Debt as part of your opportunity development and demand management practices can go a long way to minimising future Technology Debt.

Effectively Communicating Technology Debt

I’m rarely a fan of large and overly mathematical analysis (apologies to my analytical and “T” type friends!).  When trying to effectively communicate the scale, importance, urgency or obstacles that Technology Debt encapsulates, ‘awareness’ can go a long way to making sounder business and technology decisions early on in the opportunity lifecycle.  If you really need to calculate or estimate what the debt ‘is’,  there are many models out there (Google search does just fine) to perhaps approximate an ‘interest rate” that you’re currently paying.  I’ve also seen people put a simple measure (1-5 thumb in air scale) to the overall ‘debt load’ in order to better qualify IT decisions that are being made to meet business outcomes.

However, I do find the simple exercise of using terms and metaphors that both the business and IT can understand from their daily lives goes a long way.  Metaphors around building/construction are especially effective (i.e., if you buy the cheapest faucet and whack it in yourself without any knowledge of plumbing, chances are it will leak down the wall behind the sink, and soon enough you’ll be calling in a plumber to not only replace the faucet (with a better one), but you’ll probably need to bring in a builder to redo the tile behind the sink too).  Remember, if you want the message to stick, it needs to be developed in a compelling way that elicits emotion from our stakeholders.  So tell a good story about ‘Joe’ who installs his own faucet, get a few laughs and then tie into your own IT story.  Other ways to talk about it in non-technical language are things like mortgages, car payments, loan sharks, etc. – all can be effective in building an understanding of this critical concept.

How can the BRM help make a dent in Technology Debt?

The best way to dig through a pile of debt is to start with modernising and transforming business critical applications – how to know which business capabilities and processes will be most important in 2016 and beyond?  That’s the world of the BRM!  Bring that insight to IT!

This is where your relationships with IT stakeholders is critical, as this endeavour necessitates a collaborative approach.  The Enterprise Architecture (EA), Financial IT, Governance, Applications Group, Infrastructure and Operations, and Project Management Office teams all need to be brought together to discuss and realise the importance of Technology Debt in each organisation (some may not need to deal with it immediately, but all organisations should be aware of it in order not to continue to add to the pile!).

Look backwards and try to assess legacy debt, bring in the EA and IT Finance team.  Then take a look forward, what do you know about all the stages of IT Demand?  Sift through the mission-critical decisions first, as not all clunkers will lead to real debt, but having the EA team help you determine which current and future (demand) decisions may rely on legacy systems is a good start.  Can you determine whether the legacy architecture can scale and support new initiatives and whether launching a legacy modernisation effort may help IT get ahead of imminent business demand?

In the end, prevention is the best strategy and as always, culture is key.  Good Luck!

More resources you might find useful on this topic: