You're midway through a series of posts exploring the concept of an idealized "information utility" for enterprises -- something that can do a better job of handling the 97% of all corporate data that isn't mission critical.
By way of prerequisite, I'd encourage you to read this introduction, and the subsequent post on efficiency.
Ready to dig into "control" concepts?
Here we go.
What Makes Enterprise IT Different?
In a word, it's control -- control of costs, control of risks, control of outcomes. IT that isn't centrally controlled and managed isn't enterprise IT -- it's shadow IT, or a public cloud, or something else.One of the Big Learnings I've gained over the years is simple -- enterprise IT organizations exist because IT is important, complicated, risky and expensive. Conversely, if it was unimportant, simple, safe and cheap, we wouldn't need enterprise IT organizations, would we?
Control And The Information Utility
As we think about our idealized information utility, it's easy to get stuck in a paradox. On one hand, we want things to be simple and automatic -- kind of like power or phones. On the other hand, a high degree of control is needed regarding costs, risks and service levels.
How do we resolve the two?
Most people will toss out the word "policy", but there's more to it than that. I've started to use the term "policy-washing" to describe an overly simplified treatment of this discussion.
First, policies are living things. You define them, you see how they work, you change them, and you measure their results. It's better to think in term of an environment that does this holistically and adaptively, rather than the overly optimistic "set and forget" approach.
Second, every rule has its exception. There needs to be a simple mechanism for identifying and implementing exceptions to the policy as needed.
Third, no policy is an island. Change your policy on, say, dedupe efficiency -- and you might up impacting cost positively and performance negatively. Understanding these relationships and impacts is going to matter.
And, just to make things more interesting, it'd be cool if we could get users to do some of the heavy lifting in defining and monitoring policies, rather than dumping all of this on IT!
So, let's get back to our idealized information utility, and see how this all might play out.
Control Of The Information Utility At The Creation Point
The best place to start this discussion is when information is created, application is provisioned, capacity is requested, etc. No, it's not perfect, but it's a useful starting point.
At this point at time, the requestor should have to make some choices, and be prepared to understand the consequences of their choices. For example -- tell me how much, how fast, how protected, how secure, etc. -- and, as you're making these choices, this is what it's costing the business (regardless of whether there's explicit chargeback in place or not).
For example, you're a server administrator, you're provisioning that next virtual machine, here's some radio buttons to choose from, and here's the "virtual cost" of your decision. Or you're doing decision support, and you think you need a few TB for a special project. Same sort of thing applies.
Now, we know that (a) things change, and (b) people sometimes make bad choices, so how do we compensate?
Monitoring The Information Utility As Information Is Being Used
The next thing we want our information utility to do is to be smart about how the information is actually being used, and automatically adjust behavior based on reality, rather than initial intent.
This is where automatic tiering is just so damned sexy. As information is observed to be used less, it silently migrates from flash, to SATA, to advanced dedupe/compress, to spin-down -- and usually stays there!
Another example that many people don't consider is geographical location of information. In larger organizations, information is frequently created in one time zone, and used in another. If our information utility could detect this situation, and make an intelligent decision to create a local replica to improve the user experience, that'd be a neat feature as well. Or, conversely, if no one is using something, relocate it to the most cost-effective and centralized location possible.
IT also has a responsibility for what's stored in our information utilty -- a responsibility that can't be avoided.
When it comes to security and compliance, I believe this "after the fact" analysis becomes important. I don't know how many storage people understand just how advanced DLP (data loss prevention) has become, but these newer tools do a scary good job of finding information in context and taking action.
Find something that looks like financial data, a credit card, a social security number, personal information, the "f" bomb, etc.? Automatically find it and treat it appropriately. I think we'd want that option for our information utility.
Going a bit deeper, we're starting to enter a world where there are increasing regulations (and associated audits!) around restricting information location to particular geographies. I know, it sounds ludicrous to many of us, but it's a fact. It'd be nice where all of this is enforced automatically, just so we could get back to more meaningful pursuits.
The final thought here is "passing the audit". It's one thing to be compliant in how you handle information, it's another thing to prove it. And, ideally we'd spend an absolute minimum of time on the latter.
This same ability to simplify proof applies to other disciplines: security, backup, disaster recovery, etc. If someone expects you to handle information in a particular way, we'd like it not only performed automatically, but reported on automatically.
Other Aspects Of Control As Applied To An Information Utility
If there's a problem with a given service level, you'd like to be able to find and fix the problem quickly and simply. And it shouldn't take a PhD in computer science and a boatload of certifications to do this.
You'd like to keep people under some sort of soft control with how much physical storage they're using, naturally. Or, if they've decided to consume all available bandwidth, for example. Or any other untoward behavior involving a shared resource :-)
Aspects of internal service provider models will come into this. Imagine this: I'm the group lead of a bunch of developers working on an application. I have $XYZ to spend on storage-related stuff, but no more. Show my what my guys are using, and what the trends are. Kind of like how my family plan cell phone stuff works?
There's more, but I think I've covered most of the bases.
Next post is around building concepts of "choice" into our idealized information utility.
Thoughtful comments are always welcome!
Comments