In a comment exchange here a few days back, John DiMarco made some observations about how he’s handling total cost of ownership and operation (TCOO) that made a great deal of sense, so much so that today I want to highlight the thinking that underlay them.
Basically, what John was saying (visit the post Half of what you have to see the whole chain) is that he’s made decisions about what will deliver the service required. Doing that effectively is all that’s required.
He cited the example of substituting NetGear for Cisco, but there’s a deeper principle at work here.
There’s a old saying, if you work on the infrastructure end of things, that “100% is the price of admission”. All that matters to someone who wants to do something is that it works flawlessly when they want to use it.
As with Twitter yesterday, it could be flat on its back for hours and, if you don’t want to read tweets or make a tweet, that outage is irrelevant to you (as it was to me: I found out later in the day that there’d been an outage).
So, too, for what IT managers are responsible for. It needs to work well enough for the enterprise to not notice the effects of failures and trims. That means putting your money to work where it makes a difference.
Five nines or better (99.999% or more) availability on your network is meaningless, if you’ve skimped on storage to the point where the sending or receiving of four or five attachment-laden emails starts a chain of “your mailbox is almost full: delete old mail” messages and delivery to you stops until you do. Yet most organizations cheerfully impose clean up activities galore on everyone who uses their systems while spending on the best equipment from the best vendors without a second thought.
I do know people who’ve filled their Gmail quota up — but not many of them. I know hundreds who wrestle with “which emails to delete” on a weekly (and sometimes a daily) basis.
Dual lower quality networks (and in today’s world of smartphones and pads that’s not at all a silly notion) would work wonders, relative to one high reliability one, for most people’s needs. Let a desktop be configured for both WiFi and a network cable; let the devices switch between WiFi and the cellular (3G or LTE) networks.
Redundancy between two lower-quality schemes works better than one “perfected” one that, when it is out of service, offers nothing. (You also get other benefits by thinking mobile.)
The same for applications: if you have applications accessible via client code or on-device apps, also have a web interface available for the days when the devices have their problems. (These sort of notions come out of business continuity planning — but there’s no reason your backup ways of working shouldn’t be a normal part of usage.)
Investing in backup automation and local storage — the equivalent of Apple’s Time Machine on Mac OS X running constantly on your network (not just once/day) — may be a better choice from a TCOO point of view than forcing all data to be server resident and investing in server redundancy (RAID arrays, duplicate pathing, etc.). These sorts of decisions require testing. Too often we think we’ve solved the problem “forever”, instead of periodically retesting our solutions in the face of new options.
These are just a few simple examples. John’s comments have me thinking … and they should have you thinking, too.