By Leon Adato, Head Geek, SolarWinds
Your
first car may have had lousy seats, so you created makeshift seat covers. The
engine wasn't strong enough, but it was fine because you gunned it when it went
uphill. You had other problems with the car, but you had workarounds-until the
vehicle was more duct tape than steel.
Your
workplace IT environment is probably like this too. You have sort-of okay
equipment on deck and you're getting by. It's good enough for now, but it's
kept running by a great deal of additional work.
The
result: You're not future-proofed. You're also running from crisis to crisis.
Understand Your Technical Debt
When
you're making do, you're in what we refer to as "technical debt." Technical debt is where you make do with code or IT
products good enough for now.
It should be said, being in technical debt isn't always bad-that is, if you
make sure to fix that jury-rigged code before it's a crisis.
Paying
down technical debt isn't glamourous. On a day-to-day level, it can mean taking
developer time away from adding new software features to go back through the
code to eliminate shortcuts. In the moment, it feels like a delay. To the boss,
it can look like wasting time.
In my
experience, most organizations ignore their technical debt. It's
understandable. It doesn't feel like progress to go through a lot of tedious
code. But paying down technical debt is
progress. You're killing cyclical panic. When you're in technical debt, you run
with what you've got-until it breaks. And when it breaks, you panic. Because
your broken thing didn't fail on a set schedule, you're now on Red Alert and
you have a short repair cycle.
So, you
find a stopgap. You put a finger in the dike and solve the problem. But the
stopgap is placed on the top of several other stopgaps because you haven't been
paying down your technical debt.
Eventually,
you experience another breakage, another panic, another stopgap. You're in a
cyclical panic.
Don't Rely on Tribal Knowledge
Cyclical
panic causes another problem. Because of the many ad hoc fixes, processes
become dependent on tribal knowledge.
Tribal
knowledge exists for a variety of reasons, and it's in every office. As a
process, it can mean you put requisitions in a spreadsheet and then print them
out. The procedure says you hand them to some designated person in the office
who then inputs the data. But, they eventually leave and the entire process
collapses. No one understands how the system broke down. No one knows how
to fix it, either.
But
change comes slow. Recently, I met someone at a conference, and we spent a
while talking about advances in networking switches (as one does-or at least I do).
At the end of the conversation, he said, "Sounds great. But I have four more
years on my core switches. That's more than my budget for two years."
His
switches were already 10 years outside of the end of life. Not end of support;
end of life. But he hadn't depreciated his equipment, yet, so he was hanging on
to them.
Depreciation is the enemy of technical debt. I realize you can't have something
new and fancy all the time-at a certain point, you're going to stick with what
you have. However, future-proofing calls for a delicate balance. It's about
finding the best technology capable of solving bona fide business problems.
It's about getting the most future bang for your buck.
Of
course, that's a delicate line to walk. It even has psychological factors, like
learning to let go.
Crush the Concorde
When we
don't let go, we're in danger of falling victim to the sunk-cost fallacy. Also called the Concorde Fallacy, this logic flaw
happens when we think investments (or sunk costs) justify further expenditures.
To
understand the concept, think of the fallacy's namesake, the supersonic plane,
the Concorde. The British and French governments funded it for 27 years, long
after it was apparent there wasn't an economic case for it.
Think
of it as throwing good money after bad. In your case, you spent so much money
on IT equipment you want to maintain it and get as much use out of it as you
can-even though the equipment has long outlived its usefulness.
But if
you get new equipment, how should you make sure you've broken through and
futureproofed your equipment?
Unleash the Chaos Monkey
Whether
you're setting up a data center or establishing a team, you should ask
yourself, "How flexible is this thing?" And when the next new thing comes
along, how easy will it be for you to upgrade?
One way
to find out is to unleash the chaos
monkey.
In
programmer terms, a "chaos monkey" is a program capable of either randomly
turning things off or deleting them. It messes things up, on purpose. It tests
your software, your equipment, and staff. The idea is to figure out how quickly
you can recover from a hit-as a wargame, of course.
The
chaos monkey can also kill tribal knowledge by exposing it to everyone. I know
companies where the chaos monkey will decide individual team members must go
home-regardless of deadlines or projects. If everything stops because the team
member is gone: You have too much tribal knowledge and you're not
future-proofed.
You Can't Just Buy Your Way Into Future-Proofing
Even if
you're in some server-room utopia where vendors have provided you with
future-proofed products, you may still not be future-proofed.
That's
because future-proofing isn't about having the latest product from every
vendor-those products may not talk to each other.
Each
product must play well with the products you use. This is because it's going to
be the people and equipment in accounting working with the people and equipment
in security and sales-and so on, endlessly. It's going to be the network team
working in concert with the server and storage and developers. Products from
Brand X, Brand Y, and Brand Z will have to work together.
That's
why I think the answer lies in connected simplicity.
Simple Product, Intelligence in the Cloud
Before
I start, I'm not saying cloud-based technologies are future-proofed. But a
product named Cisco Meraki-a
line of wireless access points-may point us to where we need to go.
Meraki's
value option is having its intelligence is in the cloud. Its access points,
however, are so simple, so flexible any new capabilities are entirely software
coded. They don't require hardware replacement for every upgrade.
Sometimes,
you may need a physical replacement. A core switch needs an upgrade-but you
won't need to replace the entire switch-just a single module within the switch.
What
the customer receives is simple. But the utility is highly sophisticated.
Future-proofing
is about knowing products die. It's also about making sure those products and
programs work as far into the future as possible.
It's
about paying down technical debt. It's about unleashing the chaos monkey. But
it's also about removing the physical and sociological barriers holding teams
back.
##
About the Author
LEON ADATO, Head Geek, SolarWinds
Leon's 30 years of network and systems management and
monitoring experience spans the financial, healthcare, food and beverage, and
other industries, with 20 years focused specifically on monitoring and
management.
Before he was a SolarWinds Head Geek, Adato was
a SolarWinds software user for over a decade. He launched his IT career in 1989
and his expertise led him through roles as a classroom instructor, courseware
designer, desktop support tech, server support engineer, and software
distribution expert.