Daily Archives: January 10, 2011
The cloud/hosting Magic Quadrant audience
Simon Ellis over at LabSlice has posted a blog entry in which he notes that the recent Cloud IaaS and Web Hosting Magic Quadrant has, in his words, “an obvious bias towards delivering ‘enterprise’ cloud services“. He goes on to say, “Security, availability and professional services — Gartner is clearly responding to dot-points mentioned to them by the large corporates that consume their material. And I daresay that these companies may not be needing cloud IaaS, but just want to be part of the hype.”
I think his point is worth addressing, because it’s true that the MQ is written to an audience of such companies and is very explicit in the fact that we are rating enterprise-grade services, but not true that these companies just want to be part of the hype. That seems to be part of the confusion over what cloud IaaS is about, too. At Gartner, we’re excited by the whole consumerization-of-IT trend that intertwines with the cloud computing phenomenon. But we’re not writing for the individual dude, or the garage developers, or the rebels who want IT stuff without IT people. We’re writing for the corporate IT guy.
Our target audience for a Magic Quadrant is IT buyers — specifically, our end-user clients. They typically work in mid-sized businesses and large enterprises, but we also serve technology companies of all sizes. However, the typical IT buyer who uses this kind of research is the kind of person who turns to an analyst firm for help, which means that they are somewhat on the conservative and risk-averse side. It’s not that they’re not willing to be early adopters or to take risks, mind you. And they’ve embraced the cloud with a surprising enthusiasm. But they’re cautious. Our surveys and polls show that overwhelmingly, security is their top cloud concern, for instance — far and above anything else.
We expect that the IT buyer in our client audience is typically going to be sourcing cloud IaaS on behalf of his organization. He is not an individual developer looking to grab infrastructure with a credit card; in fact, he is probably somebody who is explicitly interested in preventing his developers from doing that. He might work for a start-up that’s looking for a cost-effective way to get infrastructure with no capex, but chances are he’s post-funding or post-revenue if his company can afford to be a Gartner client, so he he shares many so-called “enterprise” concerns — security, availability, performance, and so forth. Managed services options play into a lot of thinking, too — for established companies more in an “offload my hassle” way, and for start-ups more in a “I don’t have an operations team, really, so I’d like to deal with ops as little as possible” way. And yes, professional services can be a help — tons of our clients are head-scratching figuring out what’s the best way to move their infrastructure into the cloud.
Simon Ellis seems to think, from his blog post, that these corporate guys don’t actually need cloud, they just want to be a part of the hype. I think he’s wrong. The sheer number of actual sourcing discussions we’re having with our IT buyer clients — vendor short-listing, requirements, RFPs, contracts, etc. — make it very clear that they’re buying, right now. And they’re buying for real. Production websites / SaaS / etc., production “virtual data centers”, large-scale test-and-development virtual lab environments, cloud-based disaster recovery… This is real business, so to speak.
It’s not an overnight revolution. This is a transition. It usually represents only a portion of their overall IT infrastructure — usually a tiny percentage, although it grows over time. They usually don’t want to make any application changes in the process. They almost certainly aren’t designing to fail. Most of them aren’t building cloud-native apps — although an increasing number of them are beginning to deliberately try to build new applications with cloud-friendly design in mind. Few of them are really taking advantage of the on-demand infrastructure capabilities of the cloud. What they are doing, in other words, is not especially sexy. But they are spending money on the cloud, and that’s what matters in the market right now.
And so in the end, the Magic Quadrant is written to emphasize what we see our clients asking about right now. It’s not cloudy idealism, that’s for sure. And most deals contain some level of managed services, which is why there’s significant weighting on them in the Magic Quadrant. (Fully self-managed is nevertheless a crucial market segment that deserves its own MQ, later this year, although I think the interesting note there will turn out to be the upcoming Critical Capabilities, which is wholly focused on feature-set. Though it should be noted that even a cloud-only MQ is going to emphasize an enterprise-oriented feature-set, not a developer-centric one.)
When we were setting the evaluation criteria for this most recent MQ, we decided that the Execution axis would be wholly focused upon the things we were hearing our clients demand right now, and the Vision axis would be primarily focused upon where we thought cloud services would be going.
The immediate demands are probably most easily summed up as “improved agility at a comparable or lower cost, with no change to our applications, limited impact on IT operations, and limited risks to our business”. The ultimate compliment that one of our clients can give a cloud IaaS provider seems to be, “It works just like my virtualized infrastructure in my own data center, but it’s less hassle.” That’s what they say to each other at our end-user roundtables at conferences when they’re trying to convince non-adopters to adopt.
I’m a pragmatist in most of my published research. I think that as an analyst, it’s fun to prognosticate on the future, but ultimately, I’m cognizant that what ultimately pays my salary is an IT buyer coming to me for advice, and feeling afterwards like I helped him think through making the choice that was right for him. Not necessarily the ideal choice, almost certainly not the most forward-thinking choice, but the choice that would deliver the best results given the environment he has to deal with. Ditto for a vendor who comes to me for advice — I want to reflect what I think the market evolution will be and not what I think it should be.
I’m not here to cheerlead for the cloud. It doesn’t mean that I don’t believe in the promise of the cloud, or that I’m not interested in the segments of the market that aren’t represented by Gartner’s IT buyer clients (I’ve certainly been keeping an eye on developer-centric clouds, for instance), or that I don’t understand or believe in the fundamental transformations going on. But we’ve got to get there from here, and that’s doubly true when you’re talking to corporate buyers about what cloud-like stuff they want now.
The process of a Magic Quadrant
There’ve been a number of ongoing dialogues on Twitter, on Quora, and various people’s blogs about the Magic Quadrant. I thought, however, that it would be helpful to talk about the process of doing a Magic Quadrant, before I write another blog post that explains how we came to our current cloud-and-hosting MQ. We lay this process out formally in the initiation letters sent to vendors when we start MQ research, so I’m not giving away any secrets here, just exposing a process that’s probably not well known to people outside of analyst relations roles.
A Magic Quadrant starts its life with a market definition and inclusion criteria. It’s proposed to our group of chief analysts (each sector we cover, like Software, has a chief), who are in charge of determining what markets are MQ-worthy, whether or not the market is defined in a reasonable way, and so forth. In other words, analysts can’t decide to arbitrarily write an MQ, and there’s oversight and a planning process, and an editorial calendar that lays out MQ publication schedules for the entire year.
The next thing that you do is to decide your evaluation criteria, and the weights for these criteria — in other words, how you are going to quantitatively score the MQ. These go out to the vendors near the beginning of the MQ process (usually about 3 months before the target publication date), and are also usually published well in advance in a research note describing the criteria in detail. (We didn’t do a separate criteria note for this past MQ for the simple reason that we were much too busy to do the writing necessary.) Gartner’s policy is to make analysts decide these things in advance for fairness — deciding your criteria and their weighting in advance makes it clear to vendors (hopefully) that you didn’t jigger things around to favor anyone.
In general, when you’re doing an MQ in a market, you are expected to already know the vendors well. The research process is useful for gathering metrics, letting the vendors tell you about small things that they might not have thought to brief you on previously, and getting the summary briefing of what the vendor thought were important business changes in the last year. Vendors get an hour to tell you what they think you need to know. We contact three to five reference customers provided by the vendor, but we also rely heavily upon what we’ve heard from our own clients. There should generally not be any surprises involved for either the analysts or the vendors, assuming that the vendors have done a decent job of analyst relations.
Client status and whatnot doesn’t make any difference whatsoever on the MQ. (Gartner gets 80% of its revenue from IT buyers who rely on us to be neutral evaluators. Nothing a vendor could pay us would ever be worth risking that revenue stream.) However, it generally helps vendors if they’ve been more transparent with us, over the previous year. That doesn’t require a client relationship, although I suspect most vendors are more comfortable being transparent if they have an NDA in place with us and can discuss these things in inquiry, rather than in the non-NDA context of a briefing (though we always keep things confidential if asked to). Ongoing contact tends to mean that we’re more likely to understand not just what a vendor has done, but why they’ve done it. Transparency also helps us to understand the vendor’s apparent problems and bad decisions, and the ways they’re working to overcome them. It leads to an evaluation that takes into account not just what the vendor is visibly doing, but also the thought process behind it.
Once the vendors have gone through their song and dance, we enter our numeric scores for the defined criteria into a tool that then produces the Magic Quadrant graph. We cannot arbitrarily move vendors around; you can’t say, well, gosh, that vendor seems like they ought to be a Leader / Challenger / Visionary / Niche Player, let’s put them in that box, or X vendor is superior to Y vendor and they should come out higher. The only way to change where a vendor is placed is to change their score on the criterion. We do decide the boundaries of the MQ (the scale of the overall graph compared to the whitespace in the graph) and thus where the axes fall, but since a good MQ is basically a scatterplot, any movement of axis placement alters the quadrant placement of not just one vendor but a bunch.
Once the authoring analysts get done with that, and have done all the write-up text, it goes into a peer review process. It’s formally presented in a research meeting, any analyst can comment, and we get challenged to defend the results. Content gets clarified, and in some cases, text as well as ratings get altered as people point out things that we might not have considered.
Every vendor then gets a fact-check review; they get a copy of the MQ graphic, plus the text we’ve written about them. They’re entitled to a phone call. They beg and plead, the ones who are clients call their account executives and make promises or threats. Vendors are also entitled to escalate into our management chain, and to the Ombudsman. We never change anything unless the vendor can demonstrate something is erroneous or unclear.
MQs also get management and methodologies review — ensuring that the process has been followed, basically, and that we haven’t done anything that we could get sued for. Then, and only then, does it go to editing and publication. Theoretically the process takes four months. It consumes an incredible amount of time and effort.
(Please note that per Gartner’s social media policies for analysts, I am posting this strictly as an individual; I am not speaking on behalf of the company.)
CloudPundit: Massive-Scale Computing 