Basically, the thrust of the post was that a CIO only has to do three things:
- Eliminate risk
- Improve cycle times
- Reduce cost
Being an Ex-Vendor of converged architectures myself, I do like the idea that converged architectures solve everything. Unfortunately, this just ain't true. Sigh.
I also have a funny feeling that being a CIO comes down to more than just three things. To be fair, it's more than just a feeling. I used to run a CIO consulting program for Microsoft so I've spent quite a bit of time working with, supporting and selling to CIO's. I've spent a good portion of my life thinking about this position and what it takes to be good at it.
However, I do like this list as a conversation starter. If I was a CIO, I would definately be thinking about these three things. They're probably even in the right order. If you don't have your risks addressed, then reducing cost and improving cycle times don't matter much.
On the other hand, the blog post really misses a great opportunity when discussing risk. Risk is one of those things that seems to be widely mis-understood in the technical community. To me risk is not good or bad. Eliminating all risk is not really possible nor is it desirable in most cases. Risk is something that needs to be managed, like the weather. As they say in the Pacific Northwest, there is no such thing as bad weather, just insufficient gear. That's probably not strictly true, look at what our friends in the NorthEast are dealing with due to Sandy. The fact remains that weather must be dealt with and managed. We cannot control it just like we cannot truly control other sources of risk.
To change the saying to our purposes, let's just say that there is no such thing as a bad risk, just insufficient planning for that risk.
When thinking about risk, we must first think about our sources of risk. These may be business (the company is loosing money and fires half of IT) or Technical (the main router blows a power supply) but they also may be political (the city of New York declares your business model illegal; yes I'm talking to you Uber) or natural (Sandy puts your DC under ten feet of water). Under no circumstances can you do any one thing to manage all these sources of risk.
The next thing to consider is risk mitigation. What can I do to make this source of risk less likely to actually occur? In many cases, a strong mitigation plan can completely eliminate a source of risk. Having no single point of failure in a DC is a common example of this type of risk planning. However, this is not the best choice in all cases. For example, what happens if the object being protected is basically a throw away object?
This leads us to contingency planning. In some cases, it's simpler and easier to simply mitigate the risk once it occurs instead of making the risk less likely to occur. For example, I used to back up my laptop once a week. Honestly, it was a pain in the butt and I didn't remember every week. Now, I used a cloud based storage platform (SkyDrive in my case) so there's nothing on my laptop that's not replicated to the cloud. No need to backup any more. If the laptop dies, then it dies. No data is lost. Should I bother spending huge amounts of time on keeping my laptop healthy? No. Should I bother buying a second hard drive to mirror my local drive? No. There is no point.
When deciding which sources of risk to focus on, think about the probability that the risk will occur multiplied by the business impact (measured in dollars). The risks with the highest probability and the highest impact are naturally more important than those with relatively small impact or extremely low probability. Unlike the blog post above, there is no way you can afford to completely mitigate all risk. You can reduce your risk profile but you cannot take it down to zero.