Another day, another great customer conversation.
This week's extremely cool meeting was all about sketching out a storage architecture at considerable enterprise scale.
And we came up with a simple way of thinking about the problem that turned out to be very useful.
The Problem
This particular customer had come up with a very quick plan to shift their overall cost basis for IT (and storage). Due to a variety of factors, they wanted to refresh most of their landscape during the 24 months, but had to show a number quick wins early on in the process.
We're talking some serious scale here -- multiple data centers around the world, some fairly hairy applications, and -- of course -- multiple political agendas. Hanging over it all, an undeniable sense of urgency.
These exercises can become painfully complex if you get lost in the details. I made a point of trying to keep the discussion as simple as possible, yet capture the key elements that would make the difference for them.
These sorts of engagements can easily turn into product pitch and chest-beating exercises from a vendor. I made a point of not talking about specific products, but rather how we -- as EMC -- saw the industry evolving over the next few years. When I needed specific examples, I made an effort to talk about non-EMC products as well.
I think this mindset was appreciated all around.
Coming Up With Design Criteria
Of course, we reviewed all sorts of technology that was available now, and what we thought would be coming into the market through 2012, whether it be from EMC or someone else.
But we needed more than a laundry list of cool technology, we had to put together a framework for thinking about the problem itself.
After a while, we agreed to come up with a set of overall design criteria that made it far easier to sketch out a proposed architecture that the customer could grow into.
Maybe call this a meta-architecture?
- Establish a Tiered Service Catalog
I know this sounds simple, but it appeared they'd made a start on this but hadn't really reached the finish line. They needed more buckets, and they needed to disassociate the service levels from specific technologies.
Most importantly, they had to stop telling their users what they were doing, and how they were doing it. User conversations should only be about required services and costs, and not about underlying technology.
They had gotten into a bad situation where powerful users were dictating specific technologies for IT to use -- right or wrong, it had to stop.
I also insisted that they establish a period refresh process for the service catalog -- actual vs. target true-ups, new types of services, new costs for existing services, etc.
- Tiers, Tiers and More Tiers
As we went through all the current and future storage media choices, it became pretty clear that each represented a potentially useful tier in their environment. There were going to be many more choices, and the distinctions between the choices were getting wider and wider.
That included things like enterprise flash, dedupe, spin-down, compliant, etc.
They needed to know what the state of each media technology was, and what it was likely to do in the future. And, more importantly, they needed a simple way to exploit current and future storage media technologies and not disrupt everything else.
- Target A Virtualized End State
This is turning out to be *the* question in these discussions.
Simply put -- do you guys want to be near-100% virtualized, or not? I'm not saying you can (or should) get there today, or that there won't be exceptions, but -- what's the desired end state look like?
If you're assuming a preponderance of something like VMware everywhere, that sole assumption changes many aspects of how you'd ideally do things. If not, we have to think about the problem differently.
Turns out that -- yes -- they had a general bias in that direction, but hadn't formally declared their end-state intent. After a bit of discussion, we proceeded under the assumption that they'd work to become 100% virtualized.
Formal memo to follow :-)
- Choice Really, Really Matters
They thought it essential that they have at least two viable vendor choices for each part of their proposed architecture. They'd get familiar with their favorite, but keep the other one around "just in case".
Despite the fact that I work for EMC, and have certain natural biases, I thought this was a very smart approach.
But this brought up the inevitable debate of how best to use vendors. On one hand, a single-vendor type of environment was attractive from an implementation, integration and simplicity perspective. On the other hand, having all your eggs in one (vendor) basket creates new concerns, doesn't it?
In a moment of typical honesty, I told them that I thought the best approach I'd seen for circumstances like theirs was an 80/20 split. Choose a primary vendor, and hold them accountable for the majority of the landscape. But keep a second vendor around, just in case.
I don't know if the EMC sales guys appreciated by views, but it had to be said. I also shared that sometimes we were the 80% vendor, and sometimes we were the 20% vendor. Either way, we were 100% on our toes all the time.
- Separate Functional Layer
We spent some time arguing the pros and cons of where storage functionality should go. Now, remember that they wanted choices in their architecture - given their situation, it was absolutely essential.
We ended up agreeing that key functionality choices (replication, virtualization, encryption, etc.) would best be done outside the storage array, preferably in the storage fabric. Storage arrays would ideally present different tiers of service; everything else would ideally be done external to the array.
Even though there are lots of good array-based technology to do, for example, different flavors of local and remote replication, that sort of design got in the way of the need for different vendor choice.
It'd also be nice to upgrade your storage without upgrading your replication, or vice versa. Same general discussion for virtualization, although we defined the virtualization requirement a bit differently than you'd think, given that they had multiple, large data centers.
File management functions went down a similar path. We ended up that certain file management functions (virtualization, archiving, compressing, etc.) would best be done at the network layer, and independent of any vendor's array or filer.
- Invest In Tools And Process
Anyone in manufacturing learns to think in terms of fixed and variable costs. In this proposed environment, there was a strong desire to absolutely minimize variable costs, and invest in fixed costs to do so.
Put that way, this inevitably implies a thorough investment tools and process, which is essentially a fixed cost. We're talking full-boat storage and server management frameworks, ironclad ITIL processes, KPI monitoring -- the works.
And, of course, this part of the environment needed to be built so that it could run anyone's stuff, and not just EMC's.
We also had a rather frank discussion about the newer mindsets and skill sets that would be required for this environment, and different ways to meet that particular thorny objective.
- Smooth Migration Path To Disruptive Technologies
We identified several technologies that were causing them concerns -- two examples were enterprise flash drives, and FCoE.
On one hand, they understood that both were important to their storage landscape. On the other hand, they weren't ready to go all-in yet on either. All very logical.
The design principle we identified was "smooth migration" -- don't put in anything that couldn't support the new technology in an integrated fashion.
Now, if we go back to the multiple vendor principle above, this meant a certain leap-of-faith in vendors' roadmaps, since there are very few shipping examples of some of this stuff.
That being said, I told them that we thought more options would be available shortly, both from EMC and our competitors.
- Geographic Independence Of Storage And Applications
Now, please remember, we're going out a ways in the timeline here, but -- since they had multiple big data centers around the globe -- they had a certain gleam in their eye that -- one day -- they'd be able to pool all the resources in every data center, and move things around with a minimum of fuss.
Now, we both know that doing that today would be an extremely complex and expensive proposition, but there are certain technology themes that point to that sort of capability being more accessible before too long. So we made sure that we left room in the design for potential emergence of those capabilities.
There were a few other design principles we threw in, but these were the major themes.
Business Strategy Matters
This particular group had a charge-back relationship with their business customers. And, in some cases, the business units had elected to go elsewhere for certain IT services, which set up an outsourcing or service provider dynamic for this particular group.
They were between a rock and a hard place.
On one hand, the business drove them to provide the absolutely cheapest solution up-front. On the other hand, as IT people, they knew that those same customers needed additional performance, availability, security, etc.
I offered up something that I'd seen other outsourcers and service providers do with their service catalogs -- position low, and then upsell.
The initial offer should be as cheap, quick and painless as possible. And in order to upsell, I offered they needed an "IT advisor" function to go back to that same business unit and educate them on all the wonderful things that could be done -- at a very reasonable additional cost.
Getting back to infrastructure, this became another important design principle: the ability to "flex" different services using the same basic infrastructure.
Most importantly, they'd find it inconvenient and expensive if they built environment A to be really cheap, environment B to be really fast, environment C to be really HA, and so on.
What they needed was a single environment where different value-added services could be turned on and off at will, and without a lot of disruption or effort on their part. And that they should get buy in from the business types that, yes, this was a desirable thing.
Current technology supports much of this sort of thinking today. And I think we'll only see more of it in the future.
There Was More
Towards the end, we were really cooking. We ended up showing most of these ideas on a single slide. Why? Because I have this fixation that big ideas are best expressed on a single conceptual slide, and without the need for 4 point fonts, either. And they had a lot of people to convince of their thinking.
But they were out of time, and so were we. Our session came to a close.
They got a useful thumbnail sketch of a meta-design for a next generation storage architecture. I think it'll work for them pretty well.
And I got yet another wonderful customer experience to add to my collection.
Comments