We, as technology vendors, are collectively obsessed with products and technologies -- not only our own, but those of our competition.
Our fixations on debating the merits of Product A vs. Product B, C and D inevitably draw other groups in: partners and customers. Any random walk of the interwebs will show countless opinions, comparisons, debates, shouting matches, etc. along these lines.
All of this may not be particularly productive, but I guess it's entertaining to all the participants -- sort of the way people tend to debate sports. But getting stuff done in IT is a serious endeavor for most people; the outcomes matter so much more than how your favorite team is doing.
Here at EMC, we've started to make some changes to improve the situation. We've begun to shift our discussion from products to workloads. We talk about use cases and customer requirements first, and then debate the merits of one approach over another in a specific context.
In addition to sharing how we're trying to improve the discussion, I'd like to enlist your help in encouraging others to do the same.
The Incredible Diversity In IT
Spend anytime in the business, and you'll come away with a healthy appreciation of how many wildly different ways IT can be used in organizational settings. Although there are a variety of categorization schemae in use, they all are inexact at best.
Even within something as established a workload category as -- say -- Microsoft Exchange -- there's even more diversity at play: scale, performance, distributiveness, availability requirements, compliance needs, workflow and app integration. Nothing can be neatly categorized it seems -- it's all one big "it depends ..."
That's on the the demand side of the equation. The supply side has identical challenges.
Take something as familiar as storage. There are many dozens of vendors, several dozen relevant technologies being discussed, multiple management models, multiple consumption models, etc. etc. The same is true of networks, databases, development tools, management frameworks, applications, etc. -- any and all categories of IT stuff that vendors sell.
Both the supply side and demand side of IT end up being spectacularly diverse.
Diversity Can Be Inefficient
Spend anytime at all working with customers, and you end up spending a lot of time working through all this diversity. It just can't be avoided. They say "Oracle database", I've now got to ask dozens of clarifying questions. I say "remote replication" and now they've got to ask dozens of clarifying questions.
Back and forth we go, from topic to topic, hour by hour.
I suppose if I worked for a smaller company -- and only had one thing to sell -- it might be simpler from a vendor perspective. But now the onus is on the customer to ask many more clarifying questions to make sure that this only thing I have to sell is the right thing for their situation.
Don't expect any sort of broad perspective from a vendor with only one thing to sell :)
How This Can Be A Challenge For EMC
A good-sized chunk of our business is storage, and consequently we've got a plethora of storage products in our portfolio: each with their unique strengths.
On the primary storage side, we've got at least four platforms (VMAX, VNX, Isilon and Atmos) with one more joining the party: XtremIO. For data protection, we have three primary backup product families (DataDomain, Avamar and Networker). Bring up remote replication, and we've got even more to talk about: Recoverpoint, SRDF, Mirrorview, VPLEX, et. al.
And we're just getting warmed up ....
While it's hard to argue the overall market success of this approach, we do end up investing a *lot* of time with customers doing the all-important back-and-forth to make sure EMC proposes the right solution for the customer's exact requirement -- both in isolation, but also in context with everything else they're doing.
How can we make the discussion simpler?
A View Of Storage Workloads
Going forward, you'll be seeing more of these kinds of charts from EMC. It was first shared publicly at our recent analyst forum, but a number of us are starting to use it in customer discussions as it helps focus the discussion more quickly.
It's a representation of storage workloads where EMC currently has strong offerings.
The top-to-bottom axis is performance vs. capacity -- simple enough to understand. Now, plenty of exceptions abound in the real world, but -- in general -- the schema works well.
The left to right axis is "desired service levels" -- which could also be described as "storage data services". Here you have the familiar availability, replication and federation technologies. Not everyone needs three-site replication, for example.
The two axes interact: what's required for, say, adequate remote replication for a large content repository isn't going to be the same as for a mission-critical OLTP application or high-density VMware farm.
This Chart In Customer's Hands
Putting this chart up in front of an IT group is turning out to be very insightful as well, because you can ask all sorts of interesting and illuminating questions. How many of these do you have in your environment? Where are you invested today? Where are you experiencing the most growth? Where are you encountering the greatest challenges? And so on and so forth.
You can have a great storage workload conversation without talking about a single product or technology -- EMC's or anyone else's for that matter. Encouraging a customer team to think in terms of storage workloads (vs. the current inventory of tech they have on the floor) is turning out to be very helpful.
All things being equal, the fewer distinct storage architectures in an environment, the better. Standardization is a powerful tool when wielded appropriately.
But no single storage architecture (from any vendor) does a great job at *all* of these storage workloads. You probably wouldn't want to use your VMAX as a content repository, and you probably wouldn't want to use your Isilon to run high-end OLTP.
So the pragmatic goal ends up being as few distinct storage platforms as possible to reasonably cover the workload landscape.
A small compromise here and there, and you can drop 3-4 distinct storage platforms to maybe 2-3 in larger environments, or -- perhaps -- even a single (unified!) one if your needs are more modest and clustered.
We -- as product people -- can help this to a certain degree. For one thing, creating a certain amount of capacity, performance and feature overlap actually helps most of our customers get away with a smaller number of distinct platforms. Smaller VMAXes, larger VNXes and the like.
We also can help by adding secondary feature sets to our product platforms, e.g. a VNX NAS gateway on a VMAX, iSCSI on Isilon, file system presentations on Atmos, and so on. But this also introduces a potential for requirements mismatch -- unless you've got a clear view around *exactly* how you'll be using those secondary features.
Does This Work For You?
I think that this approach is extensible -- and can be applied to databases, servers, virtualization in all its sundry forms, and potentially much more. If the term "workload" doesn't work for you, perhaps "use case" or the more generic "customer situation"?
Regardless, I'd like to see a best practice emerge on both sides of the equation.
On the customer IT organization side, a simple big-picture presentation of workloads, along with dynamics around growth, concerns, relative importance, etc. can really kick-start a vendor conversation. Adapt this schema, or come up with a better one of your own.
More importantly, on the vendor side -- create a landscape view of customer requirements, and position where your particular offering fits best. Presuming, of course, that you can see beyond everything in the world being a potential nail for your personal hammer.
After all -- we could use the time we save far more productively :)