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.
Wanted – Cloud IaaS Expert
Back in December, I blogged about five reasons you should work at Gartner with me, and I’ve pleased to announce that Doug Toombs (formerly of Tier 1 Research / 451 Group) has joined my team.
However, Ted Chamberlin, my long-time colleague, has decided he’d like a change of pace, and has just left us for the vendor universe, and so we’re now seeking to backfill someone into his job. You can find the formal job listing here: IaaS and Managed Hosting Analyst.
In plain language, this analyst is going to spend their time assisting our clients who are trying to adopt cloud IaaS and hosting (especially managed hosting) solutions. The ideal candidate is someone who has real-world expertise with building solutions using cloud IaaS (and preferably has tried multiple cloud IaaS offerings and can intelligently discuss the pros and cons of each), or has been involved in building a cloud IaaS offering for a service provider (and is knowledgeable about the competing offerings). They’re sharp technically but also understand the needs of the business — someone who is currently in an architect role, or is working for a cloud provider, is probably the most likely fit.
If this sounds like you, please get in touch with me — send a resume in email, or ask me privately for more information. (If you applied the last time around, please feel free to get in touch again; the requirements for this role are somewhat different.)
My recent published research
I’d gotten out of the social media habit — Twitter and blogging — over the holidays and never really restarted, and now that a quarter has gone by, I’m feeling like I really ought to get back into the habit.
So, it’s time for a catch-up, starting with a round-up of my recent research, and, over the next few days, a glimpse into what I’m currently working on, what clients have been saying, and some thoughts on recent industry news.
Please note that unless otherwise stated, the research notes are available to Gartner clients only.
The Magic Quadrant for Managed Hosting is now out. (See the free reprint if you’re not a client.) This should have been a 2011 document, but was delivered late; consequently, there will be a late-2012 update, back on the normal publication schedule. This Magic Quadrant is being split into two regional ones — one for North America and one for Western Europe — for that late-2012 iteration. That should allow us to cover a broader set of providers and to better focus on the particular needs and desires of the two geographies, rather than presenting a single global view that has tended to be US-centric.
Our most recent set of market definitions, explanation of the market structure, and general pricing guidance can be found in the Pricing and Buyer’s Guide for Web Hosting and Cloud Infrastructure, 2012. This also explains the specific markets covered by our various Magic Quadrants.
Amazon has been a topic of great interest to all of our client constituencies. What Managers Need to Know About Amazon EC2 is a plain-language guide to this aspect of Amazon Web Services (and has some broader guidance on purchasing AWS services in general, as well). It’s targeted at an audience looking for fast facts, including non-technical audiences, like procurement managers and investors trying to get smart on what Amazon does.
The Competitive Landscape: New Entrants to the Cloud IaaS Market Face Tough Competitive Challenges is targeted at a technology provider audience (and potentially at investors). It’s a look at what’s really required to compete in the cloud IaaS market going forward, and it profiles both Amazon and CSC deeply, demonstrating two very different paths to success in this market.
Everyone wonders what cloud IaaS is being used for on a practical basis. In Case Study: Using Cloud IaaS for Business Continuity Solutions, we profile a major consumer electronics retailer, and how they use Amazon to provide a lightweight version of their website when they’re doing maintenance of their primary side, have excessive amounts of traffic, or have a primary-site outage.
Finally, on the CDN front, I’ve updated a previous note with current market info and a bit on front-end optimization: Content Delivery Network Services and Pricing, 2012.
CloudPundit: Massive-Scale Computing 