Category Archives: Analyst Life
We’re hiring a European emerging services analyst!
Gartner is hiring! Here’s the formal job posting: Research Director, Emerging Enterprise Network Services, Europe. (Or you can go to Gartner Careers and search for req 7705BR.)
Informally, here’s the scoop:
My team is looking for a European counterpart for me — someone who will be European-based, European-focused, and cover Internet infrastructure services and other emerging network services. That means following hosting, colocation, content delivery networks, cloud computing, the Internet bandwidth market, and so on. There’s a global element to this position, too, and this analyst will also deal with non-region-specific issues.
The right candidate is probably currently a senior product manager; a senior manager or director in a technical operations, product engineering, or sales engineering organization; or a senior technical evangelist. (Or they’re an analyst at one of our competitors.) They almost certainly have a background working for an ISP, carrier, Web hoster, data center outsourcer, IT consultancy with a specialization in data centers or networks, CDN, or other Internet-centric company.
This is your chance to influence the evolution of an entire industry, at a critical juncture in time. You’ll get to work with smart, self-motivated people across a wide variety of topic areas, advise executives at vendors as well as end-user organizations, and really dive into the things that interest you and our clients.
Feel free to drop me a line if you want to hear more.
What’s hot?
January was a crazy, crazy month, and February looks to be shaping up to be just as intensive, if not more so.
During January, in the fifteen available working days (the days not completely consumed by travel or by our research planning process), I had one hundred interactions — one hundred individual client/prospect inquiries or visits.
This first week of February alone, in four working days, I’m going to have thirty-four interactions. The only reason there aren’t more is that I’m physically out of schedulable hours.
What do all of these people want to talk about? Mostly cloud computing in the form of public cloud infrastructure services (40%), colocation (20%), and CDN services (20%). (Percentages are for this week.)
It’s pretty much all about cost savings, right now.
My coverage
I’ve received various queries from people, particularly analyst relations folks at vendors, trying to understand what I cover, especially as it relates to cloud computing, so I figured I’d devote a blog post to explaining.
Gartner analysts do not really have “official coverage areas” defined by titles, and our coverage shifts dynamically based on client needs and our own interests. We are matrix-managed, and our research falls into “agendas” (which may be outside our “home team”) and we collaborate across the company in “research communities”. I report into a team called Enterprise Network Services within our Technology and Service Providers group (i.e., what was Dataquest), but I spend about 90% of my time answering end-user inquiries, with the remainder split between vendors and investors. I focus on North America but also track my markets globally. I’m responding for sizing and forecasting my markets, too.
I use the term “Internet infrastructure services” to succinctly describe my coverage, but other terms, like “emerging enterprise network services” are used, as well. I cover services that are enabled by networks, rather than networking per se.
My coverage falls into the following broad buckets:
- Hosting, colocation, and the general market for data center space.
- Content delivery networks, and application delivery networks as a service.
- The Internet ecosystem, enabling technologies like DNS, policy issues, etc.
- Cloud computing.
Cloud computing, of course, is an enormously broad topic, and it’s covered across Gartner in many areas of specialization, with those of us who track it closely collaborating via our Cloud research community.
My particular focus in the cloud realm is on cloud infrastructure services — public clouds and “virtual private” clouds, on the infrastructure side (i.e., excluding SaaS, consumer content/apps, etc.). Because so many of these services are, in their currently-nascent stage, basically a way to host applications built using Web technologies, and compete directly in that same market, it’s been a very natural extension of my coverage of hosting. But by the nature of the topic, my coverage also crosses into everything else touching the space.
Our end-user customers (IT managers and architects) ask me questions like:
- Help me cut through the hype and figure out this cloud thing.
- Help me to understand what cloud offerings are available today.
- Given my requirements, is there a cloud service that’s right for me?
- What short-list of vendors should I look at for cloud infrastructure?
- What’s the cost of the various cloud options?
- What should I think about when considering putting a project in the cloud?
- What will I need to do in order to get my application to run in the cloud?
- What best practices can I learn from cloud vendors?
Our vendor customers ask me questions like:
- How is the cloud transformation going to affect my business?
- What do users care about when purchasing a cloud service?
- What does the competitive landscape look like?
- What should I be thinking about in my three-year roadmap?
- What are the technologies that I should be exploiting?
- Who should I acquire for competitive advantage?
My research is primarily grounded in the here-and-now — from what’s available now, to what’s going to be important over the next five years. However, like everyone who covers cloud computing, I’m also hunched over the crystal ball, trying to see a decade or two into the future. But companies buy stuff thinking about their needs right now and maybe their needs three years out, and vendors think about the next year’s product plans and how it positions them three years out, so I’m kept pretty busy dealing within the more immediate-term window of “how do I cut through the hype to use cloud to bring measurable benefit to my business?”
Clear Card and frequent travel
It’s Inauguration Day, but I am on the road, so I am watching TV from my hotel room rather than braving the crowds in DC. Fortunately, my quadrant of the DC area was still relatively tame at 7 am, and I made it to Dulles on time, where I made the mistake of using the premium security line rather than my Clear card, and my lane was essentially unmoving for a time — lots of tourists today. (By the way, kudos to the Washington Post for slimming down their mobile site today, to just a nice set of minimalistic pages focused on the inauguration and visitors to the city.)
Like many analysts, I travel a lot. Moreover, I go to a hodgepodge of destinations, making it difficult to accumulate frequent flyer miles on a single carrier. So I find myself frequently flying airlines that I do not have premier standing on.
My attempted solution to this was to get a Clear Card. My home airports — Dulles, Reagan National, BWI — got Clear early on, so it seemed like a logical choice. Applying was easy — in Dulles, there’s a kiosk for it where they can do the soup-to-nuts application, and one day, while waiting for an international flight (and therefore in possession of my passport), I went ahead and did it. My Clear card arrived promptly in the mail, and I was good to go.
Unfortunately, there are three notable aspects about Clear that severely hamper its usefulness: First, it’s available at very few airports. Second, it’s often not clear whether or not it’s available, and if you’re in an airport where it’s not (and sometimes even if you’re in an airport where it is), if you ask about it, airport personnel, including the TSA personnel, will look at you like you have grown a third head — they’ve never heard of it, and think the fact that you are asking about it (“Excuse me, is there a security line for Clear card holders at this airport?”) is annoying, weird and possibly suspicious. (And good luck getting anyone to take your Clear card as ID, as they’re supposed to do.) Third, the implementation of the Clear line varies, and its usefulness varies accordingly.
At Dulles, for instance, the Clear line is down with the employee security checkpoint, at baggage claim. It’s a separate line which usually has very few people in line, but it’s slow by comparison to the rate at which the premium security line normally moves. Most of the people now using Clear probably don’t use their card often; that’s obvious by the way everyone fumbles with the thing. (I do, too.) Moreover, from watching the way Clear users fumble with their bags, it seems like they don’t fly often. Frequent flyers usually get dealing with security down to an art form. The slowness of the passengers can offset the fact there are very few people in line — premium security at Dulles can actually be faster, especially when you take into account the out-of-the-way walk down to the Clear area and back towards the gates. That makes Clear a pricey investment for those times when I’m flying on an airline where I can’t use the premium line, or when Dulles is exceptionally crowded (or has otherwise not made expert-traveler lanes available).
By contrast, in Atlanta, the Clear line is just a separate entrance into security, just around the corner from the regular entrance. It lets you shortcut what is sometimes a very long general line, or the shorter premium line. But once you’re past the card-check, you’re waiting in the same screening lanes as everyone else.
I don’t regret getting the Clear card, but the cost-to-value ratio is a bit off. It’s $200 to slightly shorten wait times, for fairly frequent flyers who often end up on flights that don’t entitle them to use the premium security line, and who routinely use airports with Clear.
To me, this seems like an opportunity for the airlines to add value: Offer a paid upgrade that gives access to the premium security line and “zone 1” preferred upgrade, or attach it to full-fare tickets, or otherwise allow people to temporarily buy privileges.
The value, or not, of hands-on testing
At Gartner, we generally do not do hands-on testing of products, with the exception of some folks who cover consumer devices and the like. And even then, it’s an informal thing. Unlike the trade rags, for instance, we don’t have test labs or other facilities for doing formal testing.
There are a lot of reasons for that, but from my perspective, the analyst role has been primarily to advise IT management. Engineers can and will want to do testing themselves (and better than we can). Also, for the mid-size to enterprise market that we target, any hands-on testing that we might do is relatively meaningless vis a vis the complexity of the typical enterprise implementation.
Yet, the self-service nature of cloud computing makes it trivially cheap to do testing of these services, and without needing to involve the vendor. (I find that if I’m paying for a service, I feel free to bother the customer support guys, and find out what that’s really like, without being a nuisance to analyst relations or getting a false impression.) So for me, testing things myself has a kind of magnetic draw; call it the siren song of my inner geek. The question I’m asking myself, given the time consumed, is, “To what end?”
I think the reason I’m trying to do at least a little bit of hands-on with each major cloud is that I feel like I’m grounding hype in reality. I know that in superficially dinking around with these clouds, I’m only lightly skimming the surface of what it’s like to deploy in the environments. But it gives me an idea of how turnkey something is, or not, as well as the level of polish in these initial efforts.
This is a market that is full of incredible hype, and going through the mental exercise of “how would I use this in production” helps me to advise my clients on what is and isn’t ready for prime-time. An acquaintance once memorably wrote, when he was disputing some research, that analysts sit at the apex of the hype food-chain, consuming pure hype and excreting little pellets of hype as dense as neutronium. I remember being both amused and deeply offended when I first read that. Of course, I think he was very wrong — whatever we’re fed in marketing, tends to be more than overcome by the overwhelming volume of IT buyer inquiry we do, which is full of the ugly reality of actual implementation. But the comment has stuck in my memory as a dark reminder that an analyst needs to be vigilant about not feeding at the hype-trough. Keeping in touch by being at least a little hands-on helps to innoculate against that.
However, I realized, after talking to a cloud vendor client the other day, that I probably should not waste their phone inquiry time talking about hands-on impressions. That’s better left to this blog, or email, or their customers and the geek blogosphere. My direct impressions are only meaningfully relevant to the extent that what I experience hands-on contradicts marketing messages, or indicates a misalignment between strategy and implementation, or otherwise touches something higher-level. My job, as an analyst, is to not get lost in the weeds.
Nevertheless, there’s simply nothing like gaining a direct feel for something, and I am, unfortunately, way behind in my testing; I’ve got more demos accumulating than I’ve had time to try out, and the longer it takes to set something up, the more it lags in my mental queue.
New year, new companies
I thought I’d start off the New Year with a FAQ: “How do I get to talk to you about what my company is offering?” This is closely related to one of the questions that I get most frequently at conferences and networking events: “How do I get on an analyst’s radar screen?”
The answer to these questions is pretty straightforward: Make a briefing request. A big analyst shop like my employer, Gartner, has a formal process that lets any vendor request to brief analysts. We, at least, will take briefings, without prejudice, from clients and non-clients alike. (It’s just that clients are entitled to advice and feedback; non-clients are not, although we’ll generally engage in dialogs if the non-client has something interesting to say.)
To convince an analyst to take a first-time briefing, though, you need to have an elevator pitch that makes an analyst say, “Hey, this is relevant to my coverage and this is a vendor that’s doing something interesting.” Alternatively, you need to have won some high-profile deals or otherwise show evidence that you’re going to be making waves in the market. Start-ups often fail to articulate what the compelling value proposition is, or otherwise demonstrate that they’re important to know about, which leads analysts to decide that it’s not yet worth taking the time to listen to a briefing.
Analysts love cool new vendors. Talking to smart people who are doing cool things and have great insights into their markets is one of the best parts of being an analyst.
If you’re an innovative or rapidly-growing provider in my coverage space, and we’ve never spoken before, I encourage you to make a briefing request. I’m particularly interested in cloud infrastructure start-ups, at the moment.
Thirty cities
Analysts travel a lot. As I think over the year, here are the cities where I’ve visited clients during 2008…
Northeast: Baltimore, Boston, New York City, Philadelphia, Stamford, Washington DC
South: Atlanta, Birmingham, Charlotte, Memphis, Miami, Nashville, Richmond
Midwest: Austin, Chicago, Dallas/Fort Worth, Detroit, Houston, Milwaukee, Minneapolis/St. Paul, San Antonio, St. Louis
West: Las Vegas, Los Angeles, Portland, San Diego, San Jose, San Francisco
Canada: Montreal, Toronto
At Gartner’s data center conference
I’m at Gartner’s data center conference this week. My presentation (on best practices for colocation) is at Friday at 8 am, and I’m also participating in the panel for the Data Center Facilities “town hall” at 10 am on Thursday.
The rest of the time, I’ll be available for one-on-ones and the like. If you’re at the conference and want to talk about trends in cloud computing adoption, or anything related to Internet data centers, colocation, hosting, or content delivery networks, please schedule something with me — through the one-on-one process if you can, or directly via email if you’re a vendor with a product demo or the like that you want to show.
Quick CloudFront set-up
I’ve got a tiny low-traffic site that I’ve just set up to use Amazon’s CloudFront CDN. I chose to do it the trivial, painless way for now — through RightScale’s dashboard. It just took a couple of minutes, most of which was waiting for systems to recognize the changes. I frankly expect that my content will never be fresh in cache, but doing this will give me something to play with, without actually costing me some unpredictable amount of money. I’ve been meaning to do some similar tinkering with SimpleCDN, too, and eventually with the Rackspace/Limelight cloud CDN (which thus far lacks a snappy short name).
I still have to finish my cloud server testing, too, which I started a few months ago and which keeps being interrupted by other work and personal demands… I always feel a bit guilty keeping demo accounts for long periods of time.
Blog vs. research note
I’ve been grappling with finding the right balance between blogging and writing actual research notes. I am an all-at-once writer — I’m usually at my best when I sit down and write an entire research note at one go, so it comes out as one coherent whole. A research note is something that has usually percolated about in my head for a while and is now ready to be expressed in what I hope is a bit of crystallized clarity. Problematically, though, I spend nearly my entire day on the phone with clients — I often only have 15 minutes between calls, just long enough to attend to the needs of biology and deal with my email. Eight such fragments in no way equate to an actual uninterrupted two hours, or even one hour, which makes it very hard to write substantive documents.
On the other hand, I can write a blog entry in 15 minutes, or in a bunch of 15-minute fragments, because it’s far more stream-of-consciousness. It’s unpolished thought; it can be more disjointed. It can raise questions without trying to provide answers, speculate, and be wooly maunderings rather than actionable advice. It can be trivial in the broader scheme of things, but is given power by immediacy and connectedness. It’s enormously tempting to scribble things down and just let them float out into the world. I became an analyst in part because I like to write, and it’s easy to get sucked into scribbling something whenever I get a chance.
I was googling around for the thoughts of others on this subject, and I came across Andrew Sullivan’s newly-published piece in the Atlantic, “Why I Blog“. His musings in that piece have the elegance of long contemplation, and, I think, he does an excellent job of capturing the nature of blogging, writing:
A blog is not so much daily writing as hourly writing. And with that level of timeliness, the provisionality of every word is even more pressing — and the risk of error or the thrill of prescience that much greater.
Andrew Sullivan’s piece has, perhaps, one of the best indirect answers to the whole Bloggers vs. Analysts question, as well:
A traditional writer is valued by readers precisely because they trust him to have thought long and hard about a subject, given it time to evolve in his head, and composed a piece of writing that is worth their time to read at length and to ponder. Blogs don’t do this and cannot do this — and that limits them far more than it does traditional long-form writing. A blogger will air a variety of thoughts or facts on any subject in no particular order other than that dictated by the passing of time. A writer will instead use time, synthesizing these thoughts, ordering them, weighing which points count more than others, seeing how his views evolved in the writing process itself, and responding to an editor’s perusal of a draft or two. The result is almost always more measured, more satisfying, and more enduring than a blizzard of posts.
I think the need to engage with the wider community and to be more timely will inexorably push analysts towards adding blogging to their output activities (even if not employer-recognized), but it certainly won’t replace traditional research notes. Moreover, social media is here to stay in the lives of analysts; it’s useful and it’s relevant.
Forrester’s Jeremiah Owyang described 7 tenets of the connected analyst in his blog today; it’s a well-encapsulated set of thoughts on how analysts should engage with the community. To me, that emphasis on connection is a shift in the nature of analysts. Although we write research notes, our research clients probably derive the greatest value from the relationship, the one-on-one interactions that consider an individual client’s situation and provide tailored advice. Blogging, on the other hand, is a one-to-many, perhaps many-to-many, activity.
I’ll have something on the order of 800 one-on-one client interactions this year. Many of these clients will have read a research note before talking to me. But they want to talk about it — to privately ask detailed questions, to get help with their specific situation, to understand the data supporting the conclusions, and in short, to get the equivalent of boutique personalization.
Despite my belief in the value of the relatoinship, though, analyst firms, including mine, still make a lot of money off research subscriptions. And that gives me a professional responsibility to think hard about what to put in a freely-accessible blog versus what to put in a research note that people pay a lot of money for. So in the end, I think that what I’ll be blogging are the things that don’t yet make for good research notes — quick news takes, musings, interesting little tidbits, things that aren’t of ongoing interest to clients, and interaction with the broader blogosphere.
I’m curious to hear the thoughts of others on this subject, whether they’re other Gartner analysts, analysts at competing firms, our clients, or our detractors.