I love the fact that I often get to meet with the same customers and partners repeatedly. You get to see what's changed for them, and -- hopefully -- if you've been able to help out in any small way.
Such was the case earlier this week.
Last October, they were all up for extended briefings around private cloud, Vblocks and all of that. In December, they pulled the trigger. In January, their Vblock got installed. And now -- in mid-March -- they were back in EMC's briefing center.
What had changed?
Their story was a unique insight in how key decisions can make surprising impacts, and very quickly indeed.
Going Back To Last October
Customer discussions tend to fall into repeatable patterns, and strong interest in the "journey to the private cloud" topics show no sign of abating anytime soon.
That morning we were all in a big room with a big team. On their side, we had their key IT leadership, plus team leaders from many of the IT disciplines: server and virtualization team, network team, storage team, security team, ops team and maybe a few more. I forget.
Now, add in a few representatives from EMC, a few more from VMware, a few from Cisco, a few from VCE itself, and -- of course -- a few from our partner, and it was quite the gathering. Maybe 30 people in the room. Good thing we've got a few larger briefing rooms :)
Ideally, after the usual around-the-room introductions, we ask the customer to share their context: what's going on, and what's the challenge? I and others get to listen closely, ask a few quick questions, and then we're into the meat of the briefing.
My typical slot is immediately after the customer's presentation. It's my job to set the stage, get the core concepts and concerns on the table, and focus the discussion on a few key issues. I usually run through about 20-30 minutes of prepared content, and then we open it up for no-holds-barred Q+A. If it goes well, the real discussion usually comes out during the prepared material, and that's what exactly happened on this day.
You should know that I have way too much fun doing those sorts of customer and partner meetings. You can't escape from one of my sessions without a huge dose of passion, insight, irreverence and inevitably a few lame attempts at humor. That day in October was no different.
I knew what was coming, but did they?
The Technology Evaluation Trap
Most IT infrastructure groups have familiar disciplines: server, storage, et. al. As the topic of cloud is debated, the individual teams tend to go off in their own respective corners and produce their individual recommendations from their ostensibly unique perspectives.
The result is inevitably isolated visions for the idealized server architecture (from the server team's perspective), the idealized storage architecture (from the storage team's perspective), the idealized network architecture (from the network team's perspective), the idealized management environment (from the ops team) and so on.
You end up with a nice collection of beautiful stovepipe architectures -- all along traditional boundaries, and with almost no process change.
Unfortunately, that's not a cloud. Or at least, not a very good one. When each individual discipline gets up to present "their" portion of the cloud, you know it's not going to be pretty. Such was the case here.
I offered that they had two choices. They either had to start to invest in the missing cross-discipline architecture, process and integration skills needed to produce an architecture that spanned traditional disciplines, or simply decide to use a pre-architected and pre-integrated converged infrastructure like a Vblock.
The first approach would take a considerable amount of time and money, and there would be no guarantee the results would be ideal, or even usable The second approach could be implemented immediately, and with virtually no risk.
Decision point #1, I called it. There was a thoughtful pause in the discussion.
The Technology Integration And Support Trap
The discussion was moving more freely now, What about lock-in? What about being able to source any components they wanted?
Of course, I said. That's what most traditional IT organizations do -- spend a lot of time picking out the right components, evaluating them, sourcing them, integrating them and inevitably supporting not only the components themselves, but more importantly supporting how they interact :)
I asked the question -- how much IT infrastructure resource is being spent on those activities? They thought about it, and answered honestly: they weren't quite sure, but it was a lot of effort, and getting worse as their environment got more complex.
I asked my follow-up question -- did they think those sorts of activities created any sort of unique business value?
I didn't expect an answer.
I once again offered up two choices: they could continue to invest an increasing amount of their IT infrastructure in business-as-usual: evaluating individual components, qualifying them, sourcing them, integrating them, supporting them, etc. Or they could simply use something like a Vblock with its single support model, pre-integrated releases, and more.
You could spend the time you save doing things that mattered vs. doing things that didn't matter so much. And probably have a better running IT infrastructure as well.
Not a lot of pushback on that point.
And We're Off To The Races
We hit a lot of the predictable -- and somewhat deeper -- concerns after that.
Their IT funding model wasn't aligned with a shared infrastructure model. They didn't have the operational processes and associated skills and responsibilities in their existing organization. They weren't quite sure exactly what pre-defined IT projects could use the pooled cloud resources, and which ones couldn't. And a few more along those familiar lines.
None of these are new concerns. All of them are addressable -- and have been successfully addressed by other IT organizations.
But you've got to want to do it, I said.
If you're looking for reasons not to do something big and meaningful, there are always plenty at hand.
Summing Up
I made my final appeal. Going to a cloud-like IT-as-a-service model represents substantial and meaningful change. It's not about technology, it's about how you do IT. That's what makes it difficult -- and compelling -- at the same time. No pain, no gain.
If you make a decision for something like a Vblock, you're committing to change.
You're committing to spend more time on the things that matter, and less time on things that don't. You've made a decision to start using IT infrastructure vs. hand-crafting it piece-by-piece and trying to support it. And you've made a very key decision to forge a new relationship with your business users.
Pulling the trigger on your first Vblock means you've decided to stop endlessly analyzing, debating and fretting -- and you've decided to just get on with it.
They got it.
Fast Forward To Early March
I'm now meeting with them again about 6 months later. It's an entirely different mood in the room, and a very different conversation.
A Vblock 1 is now in production. It's getting surprisingly full (shocking!) so they're looking at either expanding the current one, or perhaps buying another one and putting it in their second data center.
I'm just dying to know -- "how did it go?"
Generally, very well, they shared. The Vblock showed up and became ready for production use in a matter of days. The workloads they had planned to initially target were all running well, and now a whole bunch of other workloads had emerged from the dark and misty shadows, wanting a home.
There were still a couple of rough edges around the perimeter. They weren't 100% locked in on how best to allocate costs back to users. The operational processes were rather new, and there had been a few bumps in that road. They were somewhat behind in getting IT folks trained up. There were a bunch of scripts that needed to be created to back-integrate to some pre-existing monitoring and reporting tools.
But, generally speaking, head nods and smiles all around.
What Had Changed?
My pitch last October was simple: Vblocks accelerate change. So I was fascinated to understand what had changed in their world as a result.
The first was predictable -- they now clearly recognized the need for a new infrastructure + ops org team to deliver private cloud services -- an integrated "private cloud" team?
Their business analysts -- the people who face off against the business users -- were challenged a bit to position the full potential of the new capabilities back to business users in a useful and meaningful way. Maybe a new skill set needed?
The IT finance guys were having extended discussions with the CFO around the advantages of the pooled services model, and that perhaps the old-school per-project fully allocated approach might not be optimal going forward.
I asked -- how did the IT team feel about things these days? They were quite honest -- the private cloud project was now seen as a "hero" project. There was a lot of glory to be shared with a team that hadn't had a big and highly visible win in a while.
I couldn't help but grin from ear-to-ear.
I circled back to some of their bigger concerns from last October, one of which was establishing a clear and visible traditional ROI for the project, ostensibly measured in before-and-after cost-to-serve numbers.
Yes, they'd taken a look at those numbers, and they were generally thought to be very good. But of course they hadn't really had the luxury of knowing what their real cost-to-serve was in their previous environment -- like the majority of IT organizations.
And then they said something interesting: nobody really cared much about that anymore -- the new way of doing things was so much obviously better than what they had been doing -- people's attention had now moved on to more pressing issues.
I found that particular observation rather insightful.
Why Were They Here Today?
In a nutshell, they wanted to know what else they could do with their new toy :)
And it was a great list of topics indeed.
They wanted to know what the current workload boundaries were for demanding database applications. How they could go beyond their current VDI pilot and look at a more accelerated deployment schedule. They wanted to learn more about the RSA GRC portal tools and how they worked with the Vblock. Even some strong interest in using the Vblock for self-service business analytics.
And, of course, the obligatory Vblock roadmap discussion -- and not so much the underlying individual components. Their perspective had changed substantially.
All very cool. And certainly not the sorts of value-creating topics we talked about last October.
Change had happened.
Wrapping It Up
My original premise to them back then was simple: if you've made a decision to embrace an IT-as-a-service private cloud model, a Vblock will not only get you there faster and better, it will tend to accelerate the evolution of all the soft processes around it. And that's exactly what appeared to happen here.
But, in one sense, we as technology vendors were just enablers.
It was their decision, their commitment, their hard work and their leadership.
We just gave them the tools.
Why Vblock?
The answer might be simple ….
Maybe it's time to just get on with it?
Oh, I just realised you posted about this topic not long ago. http://chucksblog.emc.com/chucks_blog/2011/02/understanding-advanced-persistent-threats.html
One marketing spin might be, "Well, it has happened to us and now we know more about it than anyone else. Our products and processes are now the best in repsonse. You should buy RSA, Mr Customer."
I suspect security experts are more paranoid and detail-oriented than myself, so the spin is probably a bad idea.
Posted by: Aaron | March 18, 2011 at 01:30 AM