As a CIO, have you
ever wondered how much debt you and your IT team owe the organization? If this
question takes you by surprise, chances are you are either clueless or most
likely like a majority of your CIO peers are guilty of evading a debt that you
think doesn't matter, shoving it under the carpet and postponing dealing with
it to a later date.
In either case,
ignorance is the real culprit, and certainly cannot be bliss considering you
might already be under a few crore of 'technical debt' or 'IT debt', as Gartner
prefers calling it. It's not too long before the debt piles on irreversibly,
until the ticking time bomb goes off.
Is Technical Debt Really a CIO's Business?
For CIOs who are
busy distancing themselves from all things technical, it will be pertinent to
note that technical debt is not a mere technical issue to be sidestepped for
the development team to deal with alone. It is very much a business issue that
deserves CIO's attention and action, and all the more so as he/she transitions
to a business focus.
Part of the problem
lies in how we define technical debt. Ward Cunningham, who coined the term,
stated that shipping first time code is like going into debt. "A little debt
speeds development so long as it is paid back promptly with a rewrite.... The
danger occurs when the debt is not repaid. Every minute spent on not-quite-right
code counts as interest on that debt," he explained.
definition is correct and means what it should, the problem lies in the
interpretations. Technical debt appears more to do with coding and therefore
appropriate to qualify as a programmer's headache alone. But, is it? In fact,
nothing could be further from the truth. And, that is where CIOs miss out the
point - that technical debt is very much their business.
Why Should it Matter to the CIO
The concept is
nothing new. But then, why bother now and why bother at all? Because, it
matters to the business - it's as simple as that. As per Deloitte when CIOs
operate like VCs, technical debt is a big part of the financial picture.
"Without a clear view of the real cost of legacy systems, CIOs lack the
information required to make effective decisions about new initiatives and
investments," the report states.
In 2010, Gartner
pegged the global IT debt at $ 500 billion, estimating it doubling to $ 1 trillion
by 2015. Though dated, the numbers nevertheless drive home the point. Latest
estimates are not available, but one can safely bet on the debt continuing to
pile on. A recent report by Deloitte, 'Technical Trends 2014, Technical Debt
Reversal', estimates approx. $ 3.61 worth technical debt per line of code in a
typical application. This can be further extrapolated to arrive at the
consolidated debt, and that would be no mean figure. And, this is only the cost
to fix the issues of code quality, and doesn't include the cost of lost
interest among CIOs stems from the mounting debt squeezing the already tight IT
budgets and stymieing the organization's growth plans. Comparable to financial
debt, if not paid back, it will channelize a major chunk of the allocated
budgets to paying interest than being used for innovation, and supporting
future growth and new opportunities. The interest here being maintenance,
re-designing and re-building of the systems.
The impact of
accumulated technical debt can be decreased efficiency, increased cost, and
extended delays in the maintenance of existing systems. "This can directly
jeopardize operations, undermining the stability and reliability of the
business over time. It also can stymie the ability to innovate and grow," the
Deloitte report elucidates the business connect.
Making the Choice: Now Vs. Later
Under pressure of
managing tighter IT budgets with greater transparency while enabling business
growth, CIOs are going to be left with only two choices: either planning out
debt reversal or compromising on the future growth and expansion plans.
Reversing technical debt can be a long-term investment, but if left unaddressed
can bankrupt the CIO's ability to plan for the future, warns Deloitte.
CIOs are being
advised to enlist debt reversal among their top priorities in 2014 and 2015,
and start planning for re-payment to ensure growth plans don't hit a roadblock.
They will ultimately need to understand the fact that the debt has to be paid
off at some point of time, and delaying it will only aggravate the associated
business risks as the debt rises.
Owning up to Fiscal Prudence
debt ties down to the development teams actually writing the code, ultimately
it is the CIO who needs to own the responsibility of fiscal prudence and ensure
the technical debt balance sheets are continuously cleared, lest it piles on to
the point of no control.
regularly repay technical debt by consolidating and revising software will
likely be better positioned to undertake investments in innovation," states the
Deloitte report. Additionally, it can help enhance the business's understanding
of IT delivery, and help the C-suite prioritize IT projects. Understanding,
containing, and mitigating technical debt can be a platform for a renewed level
of trust and transparency with the business, the report states further.
The CIO's first
step in the direction of fiscal prudence is getting a clear view of the debt,
which hitherto had been either missing or ignored. Amr Elssamadisy, Director of
Client Safety, Industrial Logic and a practitioner of Agile and Lean methods,
aptly describes the ground reality in one of his blogs written way back in
2010: 'Is Technical Debt a Technical Issue?' ".....technical debt is a symptom
of a larger problem of little to no visibility of the debt itself to anyone
other than developers and the system - i.e. the organization - creates an
environment where the technical debt is allowed to grow uncontrollably." He
hits the nail right on the head, and its relevance even today cannot be
Why Technical Debt Occurs?
'Technical Trends 2014, Technical Debt Reversal', report reveals that technical debt is often the result of making poor short-term/long-term trade-offs when architects pick products or approaches or programmers take shortcuts or use unsophisticated techniques without fully considering the ramifications and thinking through the longer term consequences of reuse. The report further states that each shortcut causes technical debt to accumulate. In that sense, technical debt is comparable to high-interest, short-term borrowing: When organizations don't pay off the debt promptly, compounding kicks in.
However, it need not always be a result of poor quality coding and designing, and often times can also be a result of pressure from business teams on timelines, or due to certain actions and decisions taken that were justified by the immediate ROI and the project requirements at that time. Larry Quinlan, Global CIO, Deloitte Touche Tohmatsu cites some examples of such scenarios in the report. For instance, skipping a software or infrastructure upgrade due to lack of a clear business benefit, building point-to-point interfaces into a small departmental app to get it into the business's hands more quickly, or choosing a product already owned to build a prototype in order to avoid the long and tedious vendor selection and procurement process.