Drills, diggers and IT. Each a means to an end not a means in themselves. What the consumer really wants is not the tool but what these tools produce. Holes, bigger holes and…well, what does IT produce?
If you’re reading this I will bet you a rare Yorkshire pound that you are involved in the IT business. But what do you produce, Dear Reader? And why?
I hope it’s none of the things in this document (ok, so I’m guilty of a few):
In Eli Goldratt’s The Goal, each person and machine in the factory was focused on the same goal: increasing sales and revenue. If what you are doing doesn’t help achieve the goal then don’t do it. If you have a choice of two activities and one increases revenue more than another: do the one that increases more revenue. If you are more focused on your individual performance at the expense of the goal: change!
What about the story about the janitor at NASA? When asked what he did, he said “I send people to the moon!” Hard to tie his “sweeping up bonus” to the success of the moon mission, but you see his point?
What about the IT guy/gal who’s working in a bank’s data center installing new Cisco UCS infrastructure to replace the old fashioned legacy stuff? Their goal isn’t “install the infrastructure”, is it? What is their goal? When I say Their I don’t mean that single person, I mean The Bank.
FWIW, here’s what I think:
- IT is no different to other industries, it’s just that while those industries build spaceships to reach the moon, we build unified infrastructure to help the 30,000 staff collaborate on the moon mission project – ie. we supply to those industries. We might not fly the ship, but we do send people to the moon.
- When we focus on the goal of sending people to the moon, and not our Visio’s of ITIL processes, then we are likely to do things that achieve the goal rather than … well, unnecessary activities that don’t reach the goal.
- The top, number #1, can’t-live-without activity that will help send people to the moon is to make it really easy to consume the IT we produce.
The cloud projects, the unified infrastructure projects, the consolidation projects, the collaboration projects, and many more, they all have a goal and that goal is best served by creating the most easy to consume IT system. Let me repeat that writ large:
The goal is best achieved by creating the most easy to consume IT system.
This is a universal ITism. If you’re a vendor or a consumer, this helps you. So, the next time you are working on an IT project think of the end goal hole and see if you’d do something different:
- During planning, think if the IT system could be used for something else to double up on value. For example, if you’re building a Cisco UCS system of 32 blades you could easily get over a thousand VMs on there but it might only be logistically possible to get a few hundred desktops per month deployed: could you repurpose that initially-underused capacity some other way? Overnight risk analysis calculations in a bank? Yes the capacity will diminish, but not for months yet. Think ROI.
- During architecture, think of how many pages of your blueprint are dedicated to helping people use the system. Where’s the Service Catalogue? Where are the tools and guidance to help operations keep the system up and reduce maintenance? Spending six weeks (or more? AGHAST!) on a design should be a crime punishable by spending a year on an IT Operations Bridge where you learn where the rubber meets the road and how adaptable designs are better than monolithic monstrosities.
- During deployment, are you involving the operations and applications people? If you aren’t then you’re deploying a castle of infrastructure and for every week you don’t collaborate with them you are widening the moat around around it, making more work for later. And in the world of cloud, crossing that moat might be too much effort.
- Looking at the handover, how easy is it for people to consume the compute, the network, the infrastructure? This means changes, most likely in ways you can’t foresee. Can your system be completely reconfigured at a logical level, or does it need rewiring in the data center? It better be the former.
- Migrating information: How do you get data in and out of it? Can I Vmotion VMs from legacy to your new infrastructure? Can I cold migrate? How? Does someone else have to work that out later, or can we make it easier for them now?
- Marketing. You have to sell your solution. Data centers are cold and lonely places. Build it and they won’t come unless you advertise, encourage, incentivise, adapt.
Take benchmarks: don’t we just love them in the IT industry? But all they are is navel gazing for geeks. There are much more important things to do to reach the goal but so many of us are addicted to them on both sides, vendor and consumer. Some out there are focused on ROI which is a measure of the consumability of IT. On this I have one thing to say:
Benchmarks are navel gazing for geek at best, bad science at worst, and don’t help you reach the goal at all.
Imagine being a restauranteur who only cares how fast his customers eat and not what they really want? Perhaps some want to eat fast, but perhaps others want him to be open 24×7 and offer healthy food? A successful restaurant has a goal of increasing revenue (not making meals!) and to do that they need to make meals (“meals to an end” ahahha) that satisfy customers’ needs. Simple but important.
I ask you again, Dear Reader, what is it that you do? And why?
No crack, dope or alcohol went into the production of this post.