Blog Archives
General Tips for Magic Quadrant briefings
Three years ago, I wrote a blog post called “What Makes for an Effective MQ Briefing?” This is a follow-up, with my thoughts somewhat more organized.
For AR and PR people, before you do anything else, if you have not read it, get and read Richard Stiennon’s UP and to the RIGHT. I cannot recommend it enough; Richard has seen the process as both a Gartner analyst and as a vendor, and it is chock full of good tips. It will help you understand the process, how the analysts think, and how you can best present yourselves.
This is part 1 of a two-part post contains the general tips. The next post contains tips that are applicable specifically to each of the three types of vendors. Every single one of these tips comes with one or more horror stories that I can tell you about past Magic Quadrant briefings. What seems obvious often isn’t.
General Tips
Pick the right presenters. You don’t need your most senior executives on the phone. You do need people who can present well, who thoroughly know the source material, and can answer whatever questions arise. Ensure that your presenters will have a good clear phone connection (use of cellphones or speakerphones should be strongly discouraged), and a quiet environment. If possible, choose presenters that speak fluent English and do not have accents that are difficult to understand — even if that requires using someone more junior and simply having the expert or executive on hand to take questions. You may even want to choose presenters that speak relatively quickly, if you feel time-crunched.
Send the presentation in advance. Ensure that you have emailed a copy of the presentation deck, in PowerPoint format, a day in advance of the briefing, to the administrative coordinator (who can take care of distributing it to the analysts). Be prepared to quickly resend it to anyone who has not received it. Do not send PDFs; analysts like to take notes on the slides. If you’re relying on a web conference, make sure that you still send the slides in advance — and get set up on it ahead of time and use a single PC to drive the whole presentation so you don’t waste time and possibly run into technical difficulties switching from screen to screen.
Be on time, and don’t waste time. Make sure that your dial-in number is distributed to everyone who needs to be on the call. Dial into the bridge early if need be. Have someone available to wrangle your executives if they’re running late. Have a backup presenter if you have an executive who’s notorious for not making meetings on time. Do not waste time making introductions. A presenter can briefly state their name and functional role (“I’m Joe Smith, and I run our support organization”) before starting their portion of the presentation. If you think your executive bios are important, include them as an appendix to your slides. Do not spend time having analysts introduce themselves; there are bios for them on Gartner’s website, and they will state their names when they ask questions.
Watch the clock. In a Magic Quadrant briefing, you typically have one hour to present your thoughts. Analysts are almost always scheduled back to back, so you will not have one minute extra to present, and may in fact have several minutes less if for some reason the analysts are held up from a previous meeting. Also, you want to have some time left for questions, so you should target a 45-minute presentation. If you think you have too many slides, you probably do. Rehearse to make sure you can get through your material in 45 minutes, if need be. Do not expect to be given the opportunity to do another briefing if you fail to finish in your allotted hour.
When an analyst prods you along, move on. One or more of the analysts may cut you short and ask you to move to the next slide or even skip a few slides. Listen to this and move on. By the time someone has gotten to the point of cutting you off, the analysts, who are almost certainly in an IM conversation with each other, have all already agreed that what you are saying is collectively useless to them, and that this part of the presentation is dull beyond enduring. If you think that there’s a really important point somewhere in what you’re saying, make it and move on. Or incorporate it into some other part of your presentation. Do not keep plodding along.
Focus on this particular Magic Quadrant’s market. If you have a broad solutions portfolio, that’s great, but remember that the analysts, and this Magic Quadrant, will be focused on something specific. The broader solutions portfolio can be worth mentioning, especially if it allows you to deliver higher-value and directly-relevant highly-integrated solutions, but not at the expense of focus on this Magic Quadrant’s topic. That topic should always be front-and-center. If you’re finding yourself wanting to instead talk about this somewhat-related market that you think you’re much stronger in, don’t — re-focus on the core topic.
Don’t talk about the market in general. Any analyst involved in a Magic Quadrant is, at least in theory, an expert on the market. They don’t want or need to hear about it. The only exception might be if you serve some specialized niche that the analyst does not often come into contact with. Your perspective on the market should be made clear by the specific actions that your company has taken, and will take in the future; you can explain your rationale for those decisions when you go through them, without doing a big up-front thing about the market.
Focus on your differentiation. The analysts want to know what you think makes you different, not just from the market leaders, but from your closest competitors. They want to know who you’re locked in bloody-knuckled combat each day, and why you win or lose those deals. But focus on explaining what you do well and where you intend to be superior in the future — don’t waste time badmouthing your competitors.
Be concrete and incorporate metrics whenever possible. Analysts hear broad directional statements all the time, and are usually unimpressed by them; they’re interested in the specifics of what you’ve done and what you’re going to do. Analysts love numbers. Their lives are full of vendors making grandiose claims, so they like to see evidence whenever possible. (For instance, are you claiming that your customers are much happier this year than last year? Show last year and this year’s NPS scores, ticket closure times, whatever — concrete evidence.) You don’t need to read the metrics. Just make the general point (“customer satisfaction has increased greatly in the last year, as our NPS scores show”), and have the metrics on the slides so the analysts can dive into them later. You can request that the metrics be kept under NDA if need be.
Disclose your future roadmap. A one-year or two-year roadmap, especially one that’s quarter-by-quarter, is going to make a much bigger impression than a general statement about aspirations. If you have to state that part of the briefing is under NDA, that’s fine; the analysts will still factor that information into the rating, implicitly. You may have great things planned, but if the analysts don’t know about them, you’ll get zero credit for those things when they consider your vision.
AR contacts for a Magic Quadrant should read everything
Something for analyst relations folks and the PR firms that help them, to take note of when participating in a Magic Quadrant:
Read every communication that you’re sent, in its entirety.
One might think this would be a simple thing, but multiple years of experience have shown that this is not the case. Granted, sometimes these communications are long, but they are long because they contain lots of information. The information is not gratuitous; it is information that you need to know.
Many vendor AR folks have told me that these communications essentially fall into the TL;DR category — they’re only glanced through. I recognize that it is only human to skim long emails, and even more human to skim through lengthy Word documents. I am resigned to the fact that you may completely ignore even the things that are in boldface type, especially if they’re in the middle of the message or at the bottom. I also recognize that it is only human to ask questions, rather than spending the time to read what you are sent.
But I must also point out that for many vendors, the Magic Quadrant is viewed as a high-stakes exercise that will consume a tremendous number of hours of your time and the time of your executives. You do yourself a disservice if you do not read every single word of every single communication that’s sent to you with regard to the Magic Quadrant. You don’t have to do so instantly, but you probably want to carefully read what you’re sent within a business day — and to take the time to mark deadlines on your calendar, add contacts to your address book, and so forth.
Gartner tries very hard, through the prescribed form-letter formats that it requires that analysts use for Magic Quadrant communications, to make sure that you get all the information that you need. It is true that we generally err on the side of providing too much detail, rather than being overly succinct. This is because we generally try to anticipate the questions that you are going to ask. Also, sometimes we are constrained by the form letter, which requires that we provide certain information in a certain format, which might not be the most concise possible approach.
Many of the analysts try to deal with your collective reluctance to read by making use of boldface and colorful text to highlight critical information, and in longer communications, to put a summary up-front so it’s instantly in front of you. However, in the end, glancing through the highlights and the summary is often not sufficient. There’s simply no substitute for reading everything.
To make sure that you do not drop critical communications into your spam folder, ensure that you whitelist the admin coordinator at Gartner (who will usually be your point of contact and will send out most of the official communications), along with each of the analysts involved in the Magic Quadrant. Analysts don’t do general email blasts. You should even consider just whitelisting gartner.com email addresses.
By the way, if you can spare the time, you also want to read the research that’s been published by the analysts who will be involved in the process, and more broadly, about your market. Some of the analysts blog, so looking through their postings may be helpful as well. Again, it’s time-consuming, but if Magic Quadrant placement is important to your company, it can give you a good idea of what the analysts will care about in their evaluation.
The art of the customer reference
In the course of my career at Gartner, and my pre-Gartner life as an engineering director who spent giant piles of money on purchasing technology that was often very early-stage, I have spoken to an awful lot of customer references. I’m about to soon dive into the reference-a-thon that a Magic Quadrant represents (we call as many as 5 references per vendor), and it’s leading me to think about what makes for a good or a bad reference, from my personal perspective. So, here are some thoughts, targeted at vendors and service providers.
Make sure your references like you. Nothing will create a worse impression than a reference that isn’t happy with you, and hasn’t been happy with you for some time. It’s fine for a reference to currently be having a transient problem, or even to have experienced some kind of disaster — that sometimes even makes for good stories about how good your support has been during the crisis. But a reference that isn’t a promoter is hugely problematic, because not only does it create a negative impression, it makes it clear that you have failed to keep track of this customer’s sentiment, and to communicate internally about it, to the point where you’re using an unhappy customer as a key reference. You should get in touch with your references on a regular basis to make sure they’re still delighted with you.
Your references should be engaged customers. Engaged customers know why they chose you (and can talk about the competition they looked at and why your solution was the best fit for them), have an opinion on their ongoing use of your product and service, and are passionate enough about it to talk about the good and the bad, what you do well and what they’d like you to improve. Customers who are just, yeah, we selected these guys and it all works okay — fine, you’ve checked the box on “you haven’t actively sucked”, but they’ve really said nothing interesting. This can be fine if you’re just offering a reference to a prospective customer (who wants to make sure that you’ve done an implementation similar to the one he’s contemplating and that it went fine), but it’s deadly in an analyst reference (because the analyst is interested in getting a first-hand picture of what it’s like to deal with you and your product/service, and someone who is neither enthused nor analytical makes for a deathly-dull and not very useful reference).
Your references should be targeted. If you are offering a reference customer to a prospect, the reference should be as similar to that prospect as possible, in terms of solution, industry, approach, and role (likely in that order). If you are offering references to an analyst, they should represent a spread of customers — different use cases, industries, and length of time they’ve been customers (from new implementations to long-term customers).
Your references should be representative. If you’re dealing with an individual customer, your references should be as close to that customer’s expected implementation as possible, even if that is exotic. But if you’re dealing with an analyst, the references should be representative of typical use cases, implementations, and customer types. If you choose to offer some more exotic outliers, great, but make sure the analyst knows that they’re not typical of your customer base. You don’t want to give the analyst the wrong impression about who you normally serve.
Your reference list should be periodically refreshed. You want references that are still actively engaged with you, and represent the current state of your business, in terms of version deployed, use case, and experience with your company. While long-term customers are sometimes nice to talk to (especially in a space where customers sign very long contracts, like 7-year outsourcing deals), for products, or for services bought on shorter contracts, current references are very important. If you are offering references to an analyst, especially in the context of a yearly process like a Magic Quadrant, do not repeat references from year to year; not only will the analyst prefer to talk to someone new, but he will wonder why you can’t easily produce new reference customers.
Ignore client relationships with analyst firms. When offering references to analysts, don’t worry about whether or not a reference has a client relationship with their firm. Reference interviews are typically conducted under NDA, and as far as I know across all research firms, without any regard to client status. Even if an analyst helped a client through the process that resulted in your being selected, he might not have gotten any feedback from the client about what has happened since. Even if the analyst has an ongoing relationship with that client, it’s usually in the context of inquiry, where the analyst, constrained by the 30-minute timeslot and the client’s specific questions, rarely gets to satisfy his curiosity. Reference interviews are very different, and the analyst conducting the interview might not be the same one as previously helped the client.
Consider supplementing references with a customer list. A list of customer logos and, if possible, a one-sentence description of their use case, can be extremely helpful for getting a better general understanding of who you serve, and what they use you for. If providing this list to an analyst, it can usually be done under an NDA.
Foundational Gartner research notes on cloud IaaS
In light of the upcoming Magic Quadrant work, I thought it would be useful to highlight research that myself and others have published that is important in the context of this MQ. These notes lay out how we see the market, and consequently, the lens that we’re going to be evaluating the service providers through.
I want to stress that service providers do not need to agree with our perspective in order to rate well. We admire those who march to their own particular beat, as long as it results in true differentiation and more importantly, customer wins and happy customers — a different perspective can allow a service provider to serve their particular segments of the market more effectively. However, such providers need to be able to clearly articulate that vision and to back it up with data that supports their world-view.
That said, if you are a service provider, these are the research notes that it might be helpful to be familiar with (sorry, clients only):
Pricing and Buyer’s Guide for Web Hosting and Cloud Infrastructure, 2012. Our market definitions are described here, in case you’re confused about what we consider to be cloud IaaS.
Competitive Landscape: New Entrants to the Cloud IaaS Market Face Tough Competitive Challenges. This describes the competitive landscape and the challenges of differentiating in this market. It also profiles two sucessful providers, Amazon and CSC, in detail. This is critical reading to understand what we believe does and does not differentiate providers.
Market Insight: Structuring the Cloud Compute IaaS Market. This presents our market segmentation; each segment is associated with a buyer profile. While our thinking has refined since this was published in early 2011, it is still an extremely important view into our thinking about customer needs.
Evaluating Cloud Infrastructure as a Service. This seven-part set of research notes describes the range of IaaS capabilities offered across the market, from the technology itself to how service is done. This provides important terminology, and is also useful for determining how competitive your offering really is. (Note that this is an early-2011 note set, so the state of the art has advanced since then.)
Evaluation Criteria for Public Cloud IaaS Providers. Our Technical Professionals research provides extremely detailed criteria for large enterprises that are evaluating providers. While the customer requirements are somewhat different in other segments, like the mid-market, these criteria should give you an extremely strong idea of the kinds of things that we think are important to customers. The Magic Quadrant evaluation criteria will not be identical (because it is broader than just large-enterprise), but this is the kind of thing you should be thinking about.
Market Trends: Public and Private Cloud Infrastructure Converge into On-Demand Infrastructure Fabrics. This describes our view of how the service provider cloud infrastructure platforms will evolve, including providing a perspective on public vs. private cloud, and developer-class vs. enterprise-class cloud.
Best Practice: Evaluate Isolation Mechanisms in Public and Private Cloud IaaS. Many service providers are using “private cloud” in ways we consider actively deceptive. This note provides a warning to IT buyers, and discusses the kinds of isolation options that are available. This emphasizes our insistence that providers be transparent about their isolation mechanisms and security controls.
Less-critical notes that cover narrower topics, that you may nevertheless want to read:
Market Insight: Customers Need Hybrid Cloud Compute Infrastructure as a Service. This describes customer requirements for “hybrid” scenarios — the need for cloud bridging into the enterprise data center, physical-virtual hybrid environments, hybrid hosting, and multi-cloud environments.
Infrastructure as a Service in the Cloud Services Value Chain. This describes the overall place of IaaS in the value chain. It explains market evolution and how this impacts upstream and downstream technology vendors; it provides our viewpoint on the channel.
Toolkit: Mitigating Risks in Cloud Infrastructure as a Service. This provides a fairly comprehensive checklist for risk assessment. You may want to think about how well your solution addresses this list of risks.
Delivery Models for Application Infrastructure in the Cloud: Beware the Lure of False PaaS. This provides software and middleware licensing models, and contrasts IaaS vs. PaaS. Pay particular attention to the importance of software marketplaces.
If you are not a Gartner client, please note that many of these topics have been covered in my blog in the past, if at a higher level (and generally in a mode where I am still working out my thinking, as opposed to a polished research position).
What would make the Cloud IaaS Magic Quadrant better?
At the risk of opening up a can of worms:
As a user of the Public Cloud IaaS Magic Quadrant — either as a technology buyer looking to make a vendor decision, or as a vendor looking to understand the market, what would make the document better?
Understand that I cannot change the process itself (which Gartner explicates to its analysts in a lengthy, excrutiatingly detailed document with oodles of accompanying paperwork, and while internally we may discuss what improvements could be made, from my perspective from a practical standpoint of an MQ being done right now, the process might as well be handed down on tablets of stone).
However, there are plenty of things that are not covered by the process, from the way communications are done to the information contained in the document. I am genuinely interested in what I can do to make the document more useful, as we embark on the 2012 update.
(Yes, we’re on a faster-than-annual update cycle due to the speed at which the market is moving.)
Free free to comment on my blog, or email me privately.
UP and to the RIGHT
Richard Stiennon, a former colleague of mine (he was a security analyst at Gartner from 2000-2004), has just written a book, “UP and to the RIGHT: Strategy and Tactics of Analyst Influence: A complete guide to analyst influence“. It’s a good guide to analyst relations in general, but it’s focused on Gartner, and especially the Magic Quadrant. If you’re someone who deals with analysts, I highly recommend it.
Chunks of the book were laugh-out-loud funny to me (and I read parts of it aloud to my husband, who works for a vendor and whose commentary on the MQ process once led to me posting on How Not to Use a Magic Quadrant with a three-frowny-quadrant graphic). Although almost a decade has passed since Richard worked here (a lot has changed since then, not the least of which is the MQ process), he’s done an excellent job in doing the research to reflect how things have evolved here — it’s still the best bit of writing I’ve seen that reflects the way that Gartner analysts work. I don’t agree with him 100%, but I think that as a broad reflection of the company, its analysts, the Magic Quadrant, and what we’re influenced by, it’s pretty much right on the money, right down to the desperation for a break in the 1-on-1 room at conferences.
(Side note: Unlike Richard and many of my current colleagues, I actually love doing 1-on-1s at Gartner conferences. You talk to a different sort of buyer at conferences — lots of mid-market CIOs, especially. They’re great conversations. However, the sheer volume is exhausting. I can end up taking 16 to 18 meetings a day at a conference — starting at 7 am and ending around 11 pm, only to go back to my hotel room and still need to answer emails. If I’m really unlucky, I will be up before 7 am to take a phone inquiry or briefing. And at Symposium especially, with the bathrooms 10 minutes away from the 1-on-1 tent, any break time vanishes quickly, and good luck getting lunch. Much like Richard writes, though, I assure you that anyone who didn’t take every last minute, or didn’t mind me getting in a few bites of food while they were talking, I remember fondly. I also clearly remember the folks who complained when I had to take an emergency bathroom break, shortchanging them five minutes of their 1-on-1 slot.)
Richard does an excellent job of emphasizing that the process of analyst influence is a long-term, year-round thing. If you’re starting it only when the MQ cycle is formally initiated, it is too late. (I’ve noted this before in my blog post about effective Magic Quadrant briefings.)
One important thing that Richard has missed, I think, is the importance of Gartner’s acquisition of the Burton Group back at the end of 2009. Gartner now calls that product “IT Professionals” (ITP), and its analysts are still a separate cadre but part of the larger research community on any given topic. ITP focuses on practitioners, and their analysts tend to be very hands-on. Many of Gartner’s recent hires into the general analyst cadre are also practitioners (i.e., folks who were in architect roles, rather than IT directors). That means that you can increasingly expect that at least one analyst involved in an MQ will work with the products hands-on to some extent, although that’s not likely the case with anything that really requires a complex implementation (like ERP, for instance).
The guerilla tactics that Richard describes are clever. I don’t know how well they work, but I suspect they exert a subtle mental tug. I can tell you that the more deeply I am acquainted with a vendor and the more frequently we interact — which does not, by the way, even require being a client — the more meaningful their Magic Quadrant write-up (although that doesn’t necessarily reflect dot placement).
Magic Quadrants are always going to be a subjective process, because in the end, rating and reviewing products, services, and companies is a subjective process. What’s important to one person is not necessarily important to another; the market viewpoint represented will reflect the consensus opinions of the analyst team involved but may also heavily tilt towards the lead analyst’s perspective on the market. In the end, even the most pedantic approach to quantitative scoring still requires judgment to award points — if five vendors all implement the same feature in slightly different ways, someone has to make a judgment call that stack-ranks them. Having experimented previously with Magic Quadrant spreadsheets that had ninety rating aspects per vendor, I can say that it was mostly a waste of time to get super-granular, as well. The Magic Quadrant is ultimately a graphical representation of a thought process; it is not a function-point analysis.
Call for vendors – 2012 Cloud IaaS Magic Quadrant
We’re about to kick off Gartner’s 2012 Cloud IaaS Magic Quadrant.
A pre-qualification survey, intended to gather quantitative metrics and basic information about each provider’s service, will be going out very soon.
If you are a cloud compute IaaS provider — that means you offer, as a service, fully-automated, self-service compute, storage, and network infrastructure that is available on-demand (think “by the hour” and not “by the month”) — you did not receive a survey last year, and you would like to receive a survey this year, please contact me via email at Lydia dot Leong at Gartner dot com.
Note: This is not hosting and this is not data center outsourcing. You should have a fully-standardized offering — one that is identical for every customer, not a reference architecture that you customize — and customers should be self-servicing (i.e., they go to your portal and push buttons to immediately, with zero human intervention, obtain/destroy/configure/manage their infrastructure), although you can optionally provide managed services.
Also note: This is not for software or hardware vendors. This is for service providers.
Bottom line: If you don’t consider yourself to be in competition with Amazon EC2 or the Terremark Enterprise Cloud, to take two well-known examples, this is not your Magic Quadrant.
Please note that receiving a survey does not in any way indicate that we believe that your company is likely to qualify; we simply allow surveys to go to all interested parties (assuming that they’re not obviously wrong fits, like software companies without an IaaS offering).
The Tip of the Spear
So I caught an interesting Horses for Sources blog post via Twitter — Phil Fersht of HfS called out a blog post of ISG’s Stanton Jones discussing the Gartner Magic Quadrant for Managed Hosting that I published earlier this year.
Stanton Jones’s argument seems to be that analysts sit in ivory towers, theorizing about suppliers, and making broad general statements about the market, whereas sourcing consultants actually get down and dirty with clients who are buying stuff. He says, “Analyst research is not at the tip of the spear, where buying and selling is actually occurring.”
However, that’s not actually true at the end-user-focused research firms like Gartner and Forrester. As an analyst at Gartner, I can do over a thousand one-on-one (or one-on-client-team) interactions in a single year. Each of those interactions represents a client who is considering what to buy (or build), and then going through the procurement cycle. They’re short-listing vendors, writing RFPs, wanting to discuss RFP responses, negotiating contracts and prices. It is absolutely the tip of the spear, and critically, over the long term, you also get feedback from the client as to the success of their initiative, so you’re hopefully not throwing out advice that turns out to fail in the real world.
So yes, something like a Magic Quadrant provides broad, generic advice (although I do try to orient my advice towards specific use cases). But that’s all that written research can get you. However, nearly every Gartner client buys access to inquiry, so that they can get those one-on-one, freewheeling entirely-custom interactions — so they can say, this is my exact situation, and get to Stanton Jones’s “I’m a multinational company who wants a company that can support a transformational infrastructure sourcing initiative” and ask which of these vendors I’d recommend.
By the way, if a client asked that question, I’d tell them, “You don’t want a managed hoster for this. Try discussing this with our strategic sourcing analysts, or with our data center outsourcing analysts.” (And it’s not improbable that this would be caught at the level of our client services organization, which would look at that question and say, gosh, this doesn’t sound like managed hosting, maybe you’d like these other pieces of more appropriate research and a discussion with these other analysts instead. For negotiating that kind of deal, by the way, Gartner has a consulting division that can do it; analysts don’t do the kind of work they, or a competitor like TPI, do.)
One more note: If I published in an MQ the feedback, good bad and ugly, that I’ve gotten from clients using service providers “on the ground”, I would never ever actually be able to get the research out, because it would undoubtedly be caught in a zillion Ombudsman escalations from the vendors. But if you talk to me on an inquiry, I might very well tell you, “In the last six months, every customer I have talked to of Vendor X has been unhappy, which represents a big swing in their historical quality of customer service,” or even “Customers who use Vendor X for Use Case A are happy, but those who have Use Case B think they lack sufficient expertise with the technology”. Client inquiry volume at a big research house like Gartner gets you enough anecdotal data points to show you trends. Clients want the ground truth; that’s part of what they’re paying an analyst firm for.
Introducing the new Magic Quadrant for Public Cloud IaaS
I’m happy to announce that the new Gartner Magic Quadrant for Public Cloud Infrastructure as a Service has been published. (Client-only link. Non-clients can read a reprint.)
This is a brand-new Magic Quadrant; our previous Magic Quadrant has essentially been split into two MQs, this new Public Cloud IaaS MQ that focuses on self-service, and an updated and more focused iteration of the previous MQ, focused on managed services, called the Managed Hosting and Cloud IaaS MQ.
It’s been a long and interesting and sometimes controversial journey. Threaded throughout this whole Magic Quadrant are the fundamental dichotomies of the market, like IT Operations vs. developer buyers, new applications vs. existing workloads, “virtualization plus” vs. the fundamental move towards programmatic infrastructure, and so forth. We’ve tried hard to focus on a pragmatic view of the immediate wants and needs of Gartner clients, which also reflect these dichotomies.
This is a Magic Quadrant unlike the ones we have historically done in our services research; it is focused upon capabilities and features, in a manner that is much more comparable to the way that we compare software companies, than it is to things like network services or managed hosting or data center outsourcing. This reflects that public cloud IaaS goes far beyond just self-service VMs, creating significant disparities in provider capabilities.
In fact, for this Magic Quadrant, we tried just about every provider hands-on, which is highly unusual for Gartner’s evaluation approach. However, because Gartner’s general philosophy isn’t to do the kind of lab evaluations that we consider to be the domain of journalists, the hands-on stuff was primarily to confirm that providers had particular features and the specifics of what they had, without having to constantly pepper them with questions. Consequently this also involved in reading a lot of documentation, community forums, etc. This wasn’t full-fledged serious trialing. (The expense of the trials was paid on my personal credit card. Fortunately, since this was the cloud, it amounted to less than $150 all told.)
However, like all Magic Quadrants, there’s a heavy emphasis on business factors and not just technology — we are evaluating the positions of companies in the market, which are a composite of many things not directly related to comparable functionality of the services.
Like other Magic Quadrants, this one is targeted at the typical Gartner client — a mid-market company or an enterprise, but also our many tech company clients who range from tiny start-ups to huge monoliths. We believe that cloud IaaS, including the public cloud, is being used to run not only new applications, but also existing workloads. We don’t believe that public cloud IaaS is only for apps written specifically for the cloud, and we certainly don’t believe that it’s only for start-ups or leading-edge companies. It’s a nascent market, yes, but companies can use it productively today as long as they’re thoughtful about their use cases and deployment approach. We also don’t believe that cloud IaaS is solely the province of mass-scale providers; multi-tenancy can be cost-effectively delivered on a relatively small scale, as long as most of the workloads are steady-state (which legacy workloads often are).
Service features, sales, and marketing are all impacted by the need to serve two different buying constituencies, IT Operations and developers. Because we believe that developers are the face of business buyers, though, we believe that addressing this audience is just as important as it is addressing the traditional IT Operations audience. We do, however, emphasize a fundamentally corporate audience — this is definitely not an MQ aimed at, say, an individual building an iPhone app, or even non-technology small businesses.
Nowhere are those dichotomies better illustrated than two of the Leaders in this MQ — Amazon Web Services and CSC. Amazon excels at addressing a developer audience and new applications; CSC excels at addressing a mid-market IT Operations audience on the path towards data center transformation and automation of IT operations management, by migrating to cloud IaaS. Both companies address audiences and use cases beyond that expertise, of course, but they have enormously different visions of their fundamental value proposition, that are both valid. (For those of you who are going, “CSC? Really?” — yes, really. And they’ve been quietly growing far faster than any other VMware-based provider, so for all you vendors out there, if they’re not on your competitive radar screen, they should be.)
Of course, this means that no single provider in the Magic Quadrant is a fantastic fit for all needs. Furthermore, the right provider is always dependent upon not just the actual technical needs, but also the business needs and corporate culture, like the way that the company likes to engage with its vendors, its appetite for risk, and its viewpoint on strategic vs. tactical vendors.
Gartner has asked its analysts not to debate published research in public (per our updated Public Web Participation policy), especially Magic Quadrants. Consequently, I’m willing to engage in a certain amount of conversation about this MQ in public, but I’m not going to get into the kinds of public debates that I got into last year.
If you have questions about the MQ or are looking for more detail than is in the text itself, I’m happy to discuss. If you’re a Gartner client, please schedule an inquiry. If you’re a journalist, please arrange a call through Gartner’s press office. Depending on the circumstances, I may also consider a discussion in email.
This was a fascinating Magic Quadrant to research and write, and within the limits of that “no public debates” restriction, I may end up blogging more about it in the future. Also, as this is a fast-moving market, we’re highly likely to target an update for the middle of next year.
Managed Hosting and Cloud IaaS Magic Quadrant
We’re wrapping up our Public Cloud IaaS Magic Quadrant (the drafts will be going out for review today or tomorrow), and we’ve just formally initiated the Managed Hosting and Cloud IaaS Magic Quadrant. This new Magic Quadrant is the next update of last year’s Magic Quadrant for Cloud Infrastructure as a Service and Web Hosting.
Last year’s MQ mixed both managed hosting (whether on physical servers, multi-tenant virtualized “utility hosting” platforms, or cloud IaaS) as well as the various self-service cloud IaaS use cases. While it presented an overall market view, the diversity of the represented use cases meant that it was difficult to use the MQ for vendor selection.
Consequently, we added the Public Cloud IaaS MQ (covering self-service cloud IaaS), and retitled the old MQ to “Managed Hosting and Cloud IaaS” (covering managed hosting and managed cloud IaaS). They are going to be two dramatically different-looking MQs, with a very different vendor population.
The Managed Hosting and Cloud IaaS MQ covers:
- Managed hosting on physical servers
- Managed hosting on a utility hosting platform
- Managed hosting on cloud IaaS
- Managed hybrid hosting (blended delivery models)
- Managed Cloud IaaS (at minimum, guest OS is provider-managed)
Both portions of the market are important now, and will continue to be important in the future, and we hope that having two Magic Quadrants will provide better clarity.
CloudPundit: Massive-Scale Computing 