Yes, I know. I've been talking about private clouds now for two years. You'd think that I'd run out of things to say before long.
No such luck. As more enterprise IT organizations start tackling this topic as a 2011 topic, I'm finding myself digging back into material from 2009 and 2010.
This post is no exception.
The setup is familiar: private cloud is now a 2011 priority project for IT, the team is starting to be assembled, but that's about it.
Where do we start?
Some Context
For me, a cloud is any IT infrastructure environment that's (1) built differently (variable pools of resources vs. static allocations, (2) operated differently (as an end-to-end set of services vs. traditional technology silos) and (3) consumed differently (convenient and variable consumption vs. traditonal IT approaches).
If it meets all three attributes, I tend to call it a cloud. If it's entirely under the control of an IT group, I call it a private cloud. I make my life simple that way.
Delivering a private cloud capability is turning out to be about 10% technology and 90% people, process and politics. Inevitably, the majority of the discussion centers around the10% technology.
I do my best to focus the discussion. The technology works pretty good, I assert. It's the other 90% where you're going to have the heavy lifting.
Drilling down, any cloud model uses different IT processes to get things done. These processes, in turn, require new roles and associated new skills. The differences can be profound.
In larger IT settings, resistance comes from two sources. One important source of resistance comes from outside of IT. These audiences may not like the way that IT does things, but they're used to the game, and are justifiably concerned when changes are afoot.
The other important source of resistance is the legacy IT function itself. Organizations tend to be social entities that have established norms that tend to resist any form of change -- no matter how beneficial it might be for the organization and its constituents.
This quickly gets us to the useful view that any private cloud project is essentially about change management.
Thinking About Change Management
If you've ever led a team (or a company!) through a transformation, you quickly realize that large-scale, top-down, end-to-end integrated change is a massive and frustrating undertaking.
Skilled practitioners will usually prefer to find a smaller-scale domain where the new principles can be put into practice; and use the results as a lighthouse or beacon for the rest of the organization.
I would argue the same holds true for private cloud projects -- it's about carving out an area where the concepts can be put into practice, validated and then expanded as appropriate.
Thinking About Starting Points
So, how might one go about identifying a starting point for a private cloud project?
Based on experience, I would offer that the first few use cases should represent "unmet needs" to the business; areas where there's a clear need and IT isn't doing a good job meeting the requirements with existing approaches.
The reason is simple: your crankiest users can be both your loudest critics and -- ultimately -- your most vocal and enthusiastic fans. And, as we'll see in a moment, these "unmet needs" are often high-value areas of the business.
Second, I'd stay away from anything that's arguable mission-critical. The processes associated with private clouds (or anything new, for that matter) take time to mature; it's this process maturity that is turning out to be the gating factor for more widespread applicability.
Pick areas where service delivery is important, but not bet-your-job critical. And, as we'll see in a moment, there are usually plenty of candidates.
Finally, pick areas that have willing and engaged users associated with them -- passionate people who are willing to wade in to the new thing, embrace it, and invest their own time in providing detailed and considerate feedback. A predominance of distanced or unengaged users is not a success factor for your first private cloud project.
My Target List Of Starting Places
Every environment is different, but -- over the years -- the same areas keep coming up, time and time again. Any one -- or hopefully, a combination -- of these areas might give you the requried "critical mass" to justify your first private cloud project.
#1 -- Application Development And Test
Got code? Most organizations do. Whether it's in-house applications, integrating existing packaged applications, customizations, migrations, etc. there's usually a bunch of people in larger IT settings playing with code.
They need infrastructure to get their job done. Usually, their needs are not a top priority for IT organizations. The frustrating part for me is that under-resourcing app dev and test appears completely counterproductive from a business perspective.
Someone's working on a software project. There's probably a business case behind this effort that has big numbers attached to it. Wouldn't you want it done as soon as possible? Forcing your developers, testers, integrators, etc. through lengthy and cumbersome processes to get the infrastructure they need elongates the delivery cycle -- raising costs, deferring benefits and (occasionally) resulting in less-than-ideal deliverables.
Doesn't it make sense to give these people a ready pool of on-demand pre-configured virtual machines to get their job done? They'll love you for it :)
#2 -- Virtual Desktop Projects
These are attractive for several reasons. First, just about every one is what I'd charitably describe as an "extended pilot", running for many quarters as the environment matures and adoption increases.
Second, there's usually no legacy to deal with. You've got a fairly clean sheet of paper to work with: both technology and processes. Third, private cloud notion of low-touch provisioning mate well with the desired state of desktop services provisioning.
And, as we all know, aggregated virtual desktop environments are bursty beasts, with all sorts of performance peaks and valleys, hence a great candidate for a cloud model.
#3 -- Self-Service Business Analytics
Go take a tour through finance, manufacturing, marketing, sales ops, etc. How many beefy desktops and servers do you find that grind through hundreds or thousands of decision support applications: reports, analysis, etc.?
These people get their data feeds from a variety of sources, internal and external. They load everything up, and then get what they want without having to talk to anyone in IT.
Why not bring them all home? Give them more speed and capacity than they ever could get in a desktop environment. Manage and protect the data centrally.
Strategically, there's a powerful argument around making desirable things easier to consume. From a business perspective, we want as many people as possible with ready access to good data and powerful analytic tools to make better business decisions as a part of their daily operation.
And making these capabilities available as-a-service is seductively compelling.
#4 -- Maturing Your VMware Farm
Lots of VMware farms out there now. Some are getting quite large: hundreds or thousands of virtual machines. All good.
But it's often the case that -- while the technology has changed -- the operational processes haven't. Workflows, roles, methods, etc. haven't been re-engineered around the newer technologies.
In these situations, it's not hard to make a case for investment in maturing a highly virtualized environment into a private cloud model by directly addressing the workflows, processes, skills, etc. that differentiate between the two.
There are other potential starting points I've seen, but these should be able to give you a sense of some likely targets. The more, the merrier :)
Common Pitfalls
You've got an initiative, you're assembling the team, and now you have a cluster of attractive first use cases to go tackle. What challenges lie ahead?
Several, actually. These may sound daunting at the outset, but -- as with anything else -- knowing about the potential roadblocks is half the battle.
#1 -- Overly Narrow Business Cases
Creating the business case for a private cloud shouldn't be hard, but is turning out to be somewhat challenging for many IT organizations. The pattern I see is familiar: they tend to define the ROI solely in narrow and simplistic cost-savings terms.
The "narrowness" part comes from targeting only the easy-to-get to numbers, e.g. capital acquisition, maintenance, licensing, etc. The softer (and often larger) numbers, such as operational effort, service delivery, environmentals, etc. often are left unexamined.
The "simplistic" part comes from the inability for many IT organizations to quantify the benefits that arise from speed and agility. This is fascinating for me, because -- as a business person -- I can easily put a dollar value on speed and agility. But it seems to escape many of the IT organizations who are assembling their first private cloud business case.
My advice? If your business case thinking is tending towards the narrow and simplistic, get some outside help. You'll be glad you did.
#2 -- Using The Legacy Organization To Produce New Results
This one is a classic. IT leadership decides it wants a private cloud, so it assigns the task as yet-another-project to the established IT team. The result? Something that looks extremely familiar :)
The existing processes and mindsets will make absolutely sure that the new thing aligns precisely with everything that has come before. Unfortunately, that's not what you were trying to achieve.
Back to my earlier themes -- at its essence, achieving a private cloud model is about change management. Separating key people from their day-to-day responsibilities is a useful way to bring about meaningful and substantial change.
My advice? If you don't have the luxury of freeing up some key players to go do the new thing (and I mean "free up" in a meaningful way!), get some temporary backfill on board to cover their day jobs. Also, consider salting the team with a few outside pros who've done this sort of work before.
#3 -- Failing To Engage Your New Users
I know, this is no deep insight, but it happens enough that it's worth calling out. A bunch of smart IT people go off to a room and design their private cloud. They build it, and then go tell their target users what they've done. Shockingly, it usually doesn't go over too well.
Done well, your private cloud is "their" IT project. It was their idea, it's their business case, it's their thing to fight for. You, the IT team, are just their to enable their desires and meet their needs :)
#4 -- Getting Too Deep Into The Technology
Private clouds are about *using* the technology, and not hand-crafting it piece-by-piece. Two traps here to be aware of.
The first is the inevitable desire from some quarters that the new stuff has to be 100% compatible with whatever stuff is already on the floor. We've got this great deal, it's what our people know, we like our vendor, etc.
While I can't argue the specifics (since I don't know what's on your floor!), I will argue that you need to have the freedom to depart from conventional wisdom (and legacy technology patterns!) if it makes sense.
The second trap is perhaps more insidious: avoiding the temptation to precisely evaluate and specify each and every component in the private cloud. Not only will this take an inordinate amount of time, but you'll be stuck with integrating and supporting the resulting hand-crafted environment.
This sort of activity can be very fun for technical types, but doesn't really deliver a lot of IT value for most organizations. Hence the strong popularity of pre-integrated and single-supported converged infrastructure, like a Vblock.
#5 -- Thinking Too Small
Any cloud model (private or otherwise) is about doing things at reasonable scale. Put differently, there are no small clouds. A natural tendency I've seen is to build something small and inexpensive (maybe a handful of servers, a smallish storage array, etc.) to "prove" the concepts, and then attempt to scale.
While there's no harm in validating individual technologies in a small-scale setting (e.g. getting comfortable with vCloud Director, for example). My problem? Small, informal projects don't get the organizational attention they deserve. And -- unless you design and plan for decent scale -- you'll find it very hard to achieve decent scale.
#6 -- Managing Expectations
Let's face it -- with a private cloud, you're trying something new. There are new tools, new processes, new skills and new roles at hand. Mistakes will happen -- it's inevitable.
So don't attempt to be perfect, or set the expectation that somehow -- miraculously -- you will be. Level-set early and often. Hold people accountable, but be prepared to learn some interesting lessons rather quickly.
#7 -- Invest In Skills
From Cloud Architect To Cloud Operations To Cloud Capacity Planner -- there are entirely new skills in play here. Whether you invest in on-the-job training, or send people to formal classes and certifications -- this is new stuff to just about everyone.
While you don't have to send the whole team to training, you will find that having a few people on hand with the required skills and mindset can make all the difference. Quick plug: the new EMC Cloud Architect certification is getting rave reviews ...
#8 -- Get On With It
Yes -- there's a clear opportunity here for analysis paralysis. So much is going on this space -- new technologies, new discussion points, noisy vendors, etc. that some teams seem to get that deer-in-the-headlights look on their face.
Pick a target, assemble a team, make your case -- and get on with it. The technology is more than sufficient for what you want to do. The enterprise experiences to date are compelling enough. Use milestone dates as forcing functions to minimize endless debate, and get something up and running.
You'll be glad you did!
By Chuck Hollis
VP -- Global Marketing CTOEMC Corporation
