In past posts, I’ve mentioned that EMC’s thinking is around information infrastructure. I thought I’d take a post or two to explain exactly what I mean by that phrase.
The case for information infrastructure is built on a few core beliefs. You either agree with these points, or you don’t.
Here are the basic ideas as I see them ...
- Information is becoming the single most valuable asset in an organization over time. Everyone is at a different point in this journey, but we frequently hear our customers starting to declare themselves “information companies”.
- This means that the role of IT will evolve from “defining and executing technology services” to “defining and executing information services”. Simply put, IT will be ultimately held responsible for the company’s information portfolio.
- Information costs a lot to own and manage. Information has to be protected against loss or misuse. And information can be exploited to create more value.
- Today, information is largely managed in individual application stacks. It’s managed one way for core applications, another way for file systems, another way for email, and so on.
- We argue that this fragmented approach causes three important problems: unnecessary costs, unnecessary risks and unexploited value.
- A new approach is needed: a common set of capabilities that store, protect, optimize and leverage corporate information assets regardless of what form they take or how they are used to support the business.
- We believe that IT organizations that embrace this approach will find lower costs, better protection against information risks, and find it easier to exploit information value in new ways.
At a high level, that’s basically the case. But, there are some assumptions embedded here that are worth exposing a bit.
- First, this implies that you have a knowledge-worker component in your organization that must integrate and analyze different kinds of information as part of your core competency. Overall, we see this as a growing trend.
If it’s just straight transactional processing, it’s a candidate for business process outsourcing, which then turns into another discussion entirely.
- Second, it implies that the information has value that is more than the sum of the pieces. If information isn’t crossing functional boundaries within your organization, it’s harder to make a case.
But, once again, we see more information flowing horizontally between different parts of a company – as well as across company boundaries in many cases.
- Third, it implies that IT leadership recognizes this trend, and makes a case that it should “own” many aspects of the corporate information portfolio. Business units have to be involved, but the value of information is often transcending any one business unit.
But this doesn't sound like me ...
If this doesn’t sound like your situation, there’s still a basis for the discussion, but it’s more nuanced.
- If you’re a service provider or outsourcer, we expect that many information infrastructure capabilities will need to be offered as a service, rather than a product.
- If you’re nothing more than a thin corporate layer over very diverse business units, then the discussion isn’t at your level, it’s at the business unit level. Then again, if there’s a case for shared infrastructure between business units, we’re back again.
- You may be in a company that only funds IT on a sponsored project basis, and thus find it difficult to fund infrastructure. There’s an interesting discussion on dealing with that situation in this book shown under "recommended reading".
The role of the service catalog
Perhaps one of the most powerful intellectual tools I’ve seen to start the infrastructure discussion is the notion of a service catalog: a set of defined services (with associated costs) that can be applied to different areas of infrastructure.
Simply put, it’s useful from clearly separating the “what” (a business discussion) from the “how” (a technology discussion). Separate the two, you can move forward. Mix the two, and you don’t know if you’re coming or going.
As an example, EMC has been helping customers to define their service level catalog for storage for several years. After a bit of analysis, the result is a short chart that specifies the different service levels required, and the costs associated with each.
The business is free to choose what it feels is an appropriate service level, and change if needed. Costs are transparent. IT is free to provide the service levels as it sees fit. The “what” has been cleanly separated from the “how”. And it’s a best practice that’s in wide use.
We also do work information protection (backup, replication, HA, etc.) that goes along the same lines. Define the service level catalog, associated costs, and let the business choose which they feel they need. IT’s job is now providing the required protection catalog in the best way. “What” separated from “how”.
Also very successful.
We’ve already started to extend the notion into other areas: security, virtualization, intelligent information management, enterprise content management, and the like. Each one is amenable to this two-step approach, and seems to produce great results.
Which naturally leads us to …
The Information Infrastructure Service Catalog
Without going into more depth, it’s easy to sketch out – at least at a high level – what a service catalog might look like for information infrastructure. Some of this we’ve already discussed:
- Storage services – aligning costs with performance and availability requirements
- Services that protect against information loss – aligning costs with availability, recovery and retention requirements
- Services that protect against unauthorized use – identifying sensitive information, and ensuring it is protected throughout its use cases
- Services that help to optimize physical resources – ensuring high utilization of assets, ability to change service levels quickly if needed (think virtualization, as an example) -- the key being to reallocate quickly and non-disruptively.
- Services that understand delivered service levels – monitoring application and process service levels, and providing real-time correlation of root causes.
- Services that help to optimize information management – automatically categorizing information and determining if it is candidate for cost-reduction, improved protection, risk mitigation, or can be exploited in new ways.
- Services that help leverage existing information to create new business process and workflows
It’s no accident that these words – store | protect | optimize | leverage – form the basis of what EMC sees as information infrastructure.
I’ve just described them as services, rather than technologies.
So, what's NOT information infrastructure?
Good question.
Sounds pretty all-encompassing, doesn’t it?
But let's be specific. It shouldn't include any particular technology or product offering. Vendors should compete for who can do information infrastructure better. Just like it is today.
Information infrastructure should be a customer-owned strategy that recognizes that information is at the center of IT. So it shouldn’t be “owned” by any specific vendor. Yes, that includes EMC.
It shouldn't be focused on individual transactional workflows and isolated cases of business logic; it should step back and look at how the information interrelates between these domains.
Now, that being said, I would argue that EMC is much farther along in creating these capabilities than most everyone else, and we think our stuff is better, but that’s the customer’s decision as they implement their specific information infrastructure strategy.
So Where Do You Get Started?
The answer is deviously simple.
It’s email.
Think of it as a trial run for all of the ideas I’ve explained here.
Everyone knows that there are all sorts of challenges with email, but no one is fighting to own them, especially a business unit. So IT is pretty much free to show thought leadership here, if they choose.
- Email crosses functional and business boundaries, and incorporates most information types.
- Information infrastructure for email has the quintessential triple-play: there’s opportunities to avoid costs (IT mandate), opportunities to avoid risk (legal mandate) and opportunities to use email information to create new business value (knowledge worker mandate).
- The associated technologies are relatively mature and are in wide use – so implementation headaches should be manageable.
- You’ll get to address a subset of the service level catalog I described above: different tiers of storage for emails of different types, different protection and risk mitigation approaches, the opportunity to optimize the landscape, service levels and information management, and – ultimately – leverage email information in new ways.
You know, it’s funny, I know customers who are on their third email project.
The first one was to lower costs.
The second one was to manage risks.
And now they’re looking at yet another one because they realize that all those damn emails have incremental business value – if they’re managed properly.
Maybe you can get ahead of the curve, design it once, and unlock different capabilities as the business understands what it has.
The journey has begun ...
I truly believe that IT has started on a journey – from being technologists to becoming informationists.
I believe that informationists will come to view the world through an information infrastructure lens – common services required to store, protect, optimize and leverage all information, wherever it might be.
And, of course, I believe that EMC customers are perhaps the best positioned of all to make this journey.
Comments