There are specific topics that will get CIO and IT leaders to vent. Talk about
show many spreadsheets bounce around through email, midyear budget cuts, or
hundreds of projects everyone won't prioritize, and you'll get an earful. But
there's one topic that will get them out of their seats and red in the face
with anger.
That topic is technical debt.
Technical debt, oh my! For CIO leading transformation programs, technical
debt represents the legacy ways of doing things and their underlying
systems. Trying to improve user experiences, become more data-driven,
migrate to the cloud, address security risk, increase the reliability of
data integration workflows, improve data quality, or pretty much any major
upgrade is slowed down by the weight of technical debt.
Three Examples of Technical Debt
There are a few reasons. First, there's technical debt and legacy systems
they inherited and now must maintain and support. So, that's an easy target,
especially if it's a mission-critical system that's been customized over the
years, sitting on dated hardware without a reliable disaster recovery
system. In other words, most ERPs that haven't found their way to the cloud.
Another source of frustration is just how hard it is to get the funding,
technology team resources, and business stakeholders to prioritize upgrades.
Some technologies come up every year during the budget season or when the
PMO reviews new initiatives, but never get the priority. That frustration
goes to anger every time the system has a major outage, and the CIO now must
be on bridge calls, join war rooms, console IT employees that lost their
weekends over the issue, and communicate with angry business users. Yeah,
that sounds like fun.
Lastly, there's the technical debt we continue to create. For every hundred
lines of code added, I'm willing to wager there's at least 30 percent of
technical debt added. It's not all about developers with lousy coding
practices or cutting corners to make a deadline. That's one source, but much
of the technical debt comes from dependencies such as when system or library
upgrades also require code changes. Or there's just a new and better way of
implementing a function, and so the legacy model is now technical debt. Or
the business is now expanding usage beyond its original goals, and now
factors limiting performance, scalability, user experience, and security are
all blocked by technical debt.
Managing Technical Debt Requires a Plan
So this is why I elected to dedicate Episode 10 of 5 Minutes with @NYIke on
5 ways to better manage technical debt.
Over the years, I've published several articles on technical debt:
No comments:
Post a Comment
Comments on this blog are moderated and we do not accept comments that have links to other websites.