So, a customer stopped me cold the other day with a very pointed question. I love when that happens.
Here's what he said:
"Look, every major player in IT is building their stack: EMC, IBM, Microsoft, Cisco, Oracle, SAP, and so on. What makes you think your stack is the better stack?"
Brutally candid, but a really, really good question.
So here's what I said.
Why Do We Have Stacks?
From a vendor side, the rationale is pretty clear.
The more of a customer's problem you can solve, the more you sell. And, in the natural evolution of IT vendor business strategy, there's a chasm that gets crossed where you realize that best-in-class in your category can only get you so far, and you need to start thinking end-to-end about customer problems.
There's also scale efficiencies on sales, support, marketing, integration -- even the alliance work I do as my day job.
EMC began this journey several years, and we've all seen the result. A few historical storage competitors (HDS, NetApp) are probably wrestling with the same business strategy problem right now.
From a customer side, the rationale is pretty clear.
Dealing with multiple vendors and doing the integration yourself (or paying someone to do it) isn't efficient. Any technology optimizations you get from a-la-carte are usually outweighed by additional complexity and inertia. And, every year, I'm meeting fewer and fewer customers who are 100% committed to best-of-breed across the board.
Interesting note: the worst offenders seem to be the IT organizations that work for technology companies. Somehow, lots of engineers end up in IT, and pragmatism suffers at the hands of theoretical technical elegance.
But, for everyone else, it's pretty clear. If you like what a vendor does, the more you can get from that vendor, the better. Scale efficiencies play here as well.
But there are a couple of ground rules to the stack game.
First, no closed stacks. Everybody wants the option of choice for different components of the stack. Maybe you decide to stick with the vendor's stack, but if you choose differently, it's a viable option and won't be made arbitrarily hard.
Second, no one vendor has the complete stack, so popular stacks have to work well together. EMC's stack has to play with Microsoft's, and Oracle's, and IBM's, and ... well, you get the idea.
The good news is that there are fewer and fewer major stacks to go integrate with. The challenging part is that it's an enormously expensive commitment to do this across entire product portfolios. But we've done it, and will continue to do it.
My day job, again.
So, Where Will You Build Your Stack From?
All large stack-building IT companies started in a part of the market that they were really good at, and built from there. IBM, Sun and HP started with their prowess in servers and operating systems. I call it a CPU-centric stack. Yes, it's morphed into lots of different areas, but -- scratch the surface a bit -- and you'll see a lot of CPU-centric thinking.
Microsoft started with their user experience and desktop experience, and used that to drive application integration and frameworks and a whole lot more. It's a very successful stack. But -- scratch the surface a bit -- and you'll see a lot of operating system thinking at the core.
Cisco started with the network. Oracle started with the database.
And EMC started with storage.
So, you might ask, why would that give us any sort of differentiation?
Of all the potential starting points, we started with storing, protecting and optimizing IT's single most valuable asset -- information.
Networks move it around, CPUs process it, databases organize it -- EMC stored it all.
And, in the process, I like to think we generally earned an enormous amount of trust from our customers in this regard.
So, whether you agree or not, scratch our surface a bit -- and you'll see a lot of information-centric thinking at the core.
And When Did You Build Your Stack?
Stacks take a long time to build. And the overall strategy is set at a point in time where there's a set of default assumptions that lead to the rationale of the stack attributes. Most of the bigger, more mature stacks trace their roots back to the 1990s, and some even the 1980s.
EMC's, by comparison, is a fairly recent stack. We built it over the last few years.
So, why is this important?
Because we had the luxury and the advantage of coming a bit late to the game, being able to look around, and see how IT had changed since the 1980s and 1990s. In the process, we came up with a very different set of stack assumptions that probably weren't on the horizon when the other guys started building theirs.
I won't paint a complete picture here, but -- embedded in our stack thinking -- there are a few obvious assertions.
- Information was going to continue to grow in importance, and would end up being the primary focal point of the IT.
- Information was going to shift from structured (think databases) to unstructured (think repositories).
- Classifying, understanding and organizing information was going to be very important, especially the unstructured stuff.
- Securing information at the information level (in addition to infrastructure) was going to be very important.
- IT resources (servers, storage, etc.) were going to be virtualized, rather than physical.
- IT resource management would have to change from managing things to managing relationships between things, hence models.
And storage -- that boring, commoditized stuff -- was going to be an interesting starting point for the stack, simply because it contained the single most precious asset in the IT environment -- information.
Simply put -- our stack is different, because we started with a different set of assumptions and perspectives.
Now, it's up to a customer to decide whether they think (a) the EMC assumptions are valid, and (b) whether they want to use none, some or all of the stack we've assembled.
And there's absolutely nothing wrong with the stacks that the other vendors have assembled. In their own way, they make a lot of sense. They solve very real problems. And some of them have been spectacularly successful.
But I firmly believe that there's also need for a different kind of stack -- an information-centric stack -- one that's both agnostic and complementary to other vendors stacks -- and that's what EMC has built.
And we'll see how EMC's thinking plays out, won't we?
Comments