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.
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).
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.
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.
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).
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.
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.
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.
Despite having made various blog posts and corresponded with a lot of people in email, there is persistent, ongoing confusion about our forthcoming Magic Quadrant for Public Cloud Infrastructure as a Service, which I will attempt to clear up here on my blog so I have a reference that I can point people to.
1. This is a new Magic Quadrant. We are doing this MQ in addition to, and not instead of, the Magic Quadrant for Cloud IaaS and Web Hosting (henceforth the “cloud/hosting MQ”). The cloud/hosting MQ will continue to be published at the end of each calendar year. This new MQ (henceforth the “public cloud MQ”) will be published in the middle of the year, annually. In other words, there will be two MQs each year. The two MQs will have entirely different qualification and evaluation criteria.
2. This new public cloud MQ covers a subset of the market covered by the existing cloud/hosting MQ. Please consult my cloud IaaS market segmentation to understand the segments covered. The existing MQ covers the traditional Web hosting market (with an emphasis on complex managed hosting), along with all eight of the cloud IaaS market segments, and it covers both public and private cloud. This new MQ covers multi-tenant clouds, and it has a strong emphasis on automated services, with a focus on the scale-out cloud hosting, virtual lab environment, self-managed virtual data center, and turnkey virtual data center segments. The existing MQ weights managed services very highly; by contrast, the new MQ emphasizes automation and self-service.
3. This is cloud compute IaaS only. This doesn’t rate cloud storage providers, PaaS providers, or anything else. IaaS in this case refers to the customer being able to have access to a normal guest OS. (It does not include, for instance, Microsoft Azure’s VM role.)
4. When we say “public cloud”, we mean massive multi-tenancy. That means that the service provider operates, in his data center, a pool of virtualized compute capacity in which multiple arbitrary customers will have VMs on the same physical server. The customer doesn’t have any idea who he’s sharing this pool of capacity with.
5. This includes cloud service providers only. This is an MQ for the public cloud compute IaaS providers themselves — the services focused on are ones like Amazon EC2, Terremark Enterprise Cloud, and so forth. This does not include any of the cloud-enablement vendors (no Eucalyptus, etc.), nor does it include any of the vendors in the ecosystem (no RightScale, etc.).
6. The target audience for this new MQ is still the same as the existing MQ. As Gartner analysts, we write for our client base. These are corporate IT buyers in mid-sized businesses or enterprises, or technology companies of any size (generally post-funding or post-revenue, i.e., at the stage where they’re looking for serious production infrastructure). We expect to weight the scoring heavily towards the requirements of organizations who need a dependable cloud, but we also recognize the value of commodity cloud to our audience, for certain use cases.
At this point, the initial vendor surveys for this MQ have been sent out. They have gone out to every vendor who requested one, so if you did not get one and you wanted one, please send me email. We did zero pre-qualification; if you asked, you got it. This is a data-gathering exercise, where the data will be used to determine which vendors get a formal invitation to participate in the research. We do not release the qualification criteria in advance of the formal invitations; please do not ask.
If you’re a vendor thinking of requesting a survey, please consider the above. Are you a cloud infrastructure service provider, not a cloud-building vendor or a consultancy? Is your cloud compute massively multi-tenant? Is it highly automated and focused on self-service? Do you serve enterprise customers and actively compete for enterprise deals, globally? If the answers to any of these questions are “no”, then this is not the MQ for you.
As I alluded to in some earlier posts, we are doing a mid-year Magic Quadrant for public cloud IaaS. Specifically, this is for multi-tenant, on-demand, self-provisioned, compute services (with associated storage, networking, etc.). That would be services like Amazon EC2 and Terremark Enterprise Cloud. The intended context is virtual data center services — i.e., environments in which a business can run multiple applications of their choice — as they would be bought by Gartner’s typical IT buyer clients (mid-market, enterprise, and technology companies of all sizes).
Vendors invited to participate will see a formal research-initiation email sometime in the next week or two (or so I hope). This is just an early heads-up.
If you are a public cloud compute IaaS provider and you didn’t participate in the last Magic Quadrant (i.e., you did not do a survey for qualification last year), and you are interested in trying to qualify this year, please feel free to get in touch with me, and I’ll discuss including you in the qualification survey round. (Anyone who got a survey last time will get one this time.) You do not need to be a Gartner client.
Of late, I’ve seen some enthusiastic PR folks sign up executives at totally inappropriate companies to talk to me about qualifying for MQ inclusion. Please note that the MQ is for service providers, not enablers (i.e., not software or hardware companies who make stuff to build clouds with). Moreover, it is for public cloud (i.e., multi-tenant elastic services), not custom private clouds or utility hosting and certainly not colocation or data center outsourcing. And it is for the virtual data center services, the “computing” part of “cloud computing” — not cloud storage, PaaS, SaaS, or anything else.