"Cloud" -- however you choose to define it -- is undoubtedly one of those big transformational waves that sweep through our industry every so often.
Regardless of what kind of IT organization you're running, if you're an IT leader, cloud concepts will undoubtedly impact how you do things going forward.
By now, there's a pattern in how the conversation usually goes with these IT leaders. The specifics might vary, but the themes don't.
What appears here is solely based on my personal experiences in many face-to-face conversations on this very topic. While not perfect nor authoritative, it's turned out to be a useful synthesis -- so far!
Phase One Discussion -- What Does Cloud Mean To Me?
I gave up trying to define "cloud" a long time ago. At this level, no one really cares about precise definitions, just the bottom line: what does all this mean to me?
No two IT situations are alike -- that's for sure. As a result, there's usually a serious conversation at the outset around mapping the potential of cloud concepts into a more specific value proposition tailored for a particular IT situation.
The starting points for this part of the discussion are always the same -- efficiency and agility -- but the specific mapping back into the business context always varies.
"Efficiency" covers a lot of conceptual ground -- it basically means getting more value back for every dollar you spend. That can be capex, open, fixed vs. variable expenditures, cost transparency, service delivery, etc. etc. Lots of different sub-cases under the broad concept -- the goal here is to find a critical mass of efficiency potential that resonates to their particular situation.
Investing in IT transformation to get meaningfully more efficient IT spend ought to be enough to make the case, but there's usually more -- and that can be a more challenging discussion.
When you start talking about "agility" to an IT leadership team, the discussion usually goes one of two ways.
The best case is that they fundamentally understand how their business users crave the ability to do new things very quickly, or -- conversely -- they get very defensive about how their existing levels of responsiveness (usually measured in months) is more than adequate at present.
If we go in the latter direction -- and the conversation is going well! -- I usually go probing around the revenue-generating side of their business, and can often come up with some "agility matters a lot" examples for them to think about.
Regardless, the closure of this phase of this part of the discussion usually revolves around a simple proposition: it's about spending less on the stuff that isn't important so you can spend more on the stuff that is important.
And there's usually general agreement around that desired state of affairs.
Phase Two Discussion -- What Makes This Hard?
At this level, you're dealing with senior IT leaders who have been around the block more than once. Simply put: nothing good is easy, and nothing easy is good.
So it's time for an honest discussion around what makes this transformation difficult.
My personal checklist of the big, hairy challenges looks something like this:
* establishing the vision, the case and sponsorship
* securing investment for the transformation
* establishing a productive governance framework
* modifying the ongoing funding model from project-based to pooled
* beginning the process of organizational transformation
* deciding which bits you'll do yourself, and where you'll need help
* finding a place to start
It's obvious that each of these are extended discussions in their own right, but I'll try to give a quick synopsis here.
The starting point should be obvious -- the need to establish the case for IT transformation, painting a vision for the end-state, and securing a critical mass of sponsorship within the organization.
Although this might sound daunting, the track record for alternative approaches doesn't seem good. There are more than a few "skunkworks" initiatives around next-gen IT going on out there. I guess the hope is that the skunkworks approach becomes so successful that magically it becomes the norm.
Anecdotal evidence shows otherwise -- the skunkworks project gets going, but inevitably stalls when it bumps up against some of the more intractable parts of the broader landscape.
Strong recommendation: investing a few weeks or months in this activity is proving to be time well spent. Conversely, if you fail to achieve success here, that might tell you something as well :-)
Changing how a part of an organization does its business requires up-front investment, and IT is no exception. Frequently, there's the hope that -- somehow -- significant transformation can be funded out of the ordinary run rate.
That'd be nice, but experience has shown that it's the rare case where significant and meaningful progress can be made by tin-cupping around the various budget pools.
In essence, you're investing in shortening the the time to value. There's some sort of payoff you've quantified at the end state; you're investing to get to that state in a handful of quarters, vs. many years.
Significant, multi-dimensional change in any large organization with multiple priorities and stakeholders inevitably means an investment in governance. We're frequently seeing multiple new IT governance functions spring up during these IT transformations to help continually balance between swift progress and minimizing disruptions.
I am not aware of any fixed recipe as to what a good governance structure might look like for your particular situation. I do know that -- done right -- an investment in setting up and driving an enhanced governance function appears to pay good dividends for those that do it.
Another issue that rears its ugly head -- and must be addressed -- is moving away from the traditional per-project approach that many organizations use for funding infrastructure. The model is familiar: business unit has project, business unit pays for additional infrastructure and associated costs in an easy-to-understand model.
However, cloud models are based on pooled resources. The funding model is more akin to what's done for shared services like networks, email and other infrastructure funding models where charging per-project makes little sense.
One of the hardest, and most important, lessons learned in the last few years is that moving to any sort of cloud-like IT-as-a-service model means significant and meaningful organizational transformation for the IT team.
We're always talking new skills, new roles and new responsibilities. There is no meaningful change without directly addressing how the technology is used to deliver the newer services that business users crave.
The level of effort -- and the various approaches -- are directly proportional to the size and the degree of entrenchment of the IT organization itself. Smaller, more progressive IT organizations are moving far faster to the new model; larger, more entrenched IT organizations have some heavy lifting ahead of them.
Deciding where you'll need outside help is an important discussion that shouldn't be overlooked. Most IT organizations are designed and built to run steady-state: they typically don't have the critical mass of skills or the resources for IT transformation.
The natural tendency -- of course -- is the do-it-yourself approach using primarily internal resources. However, selective use of outside resources has repeatedly proven to both accelerate the journey and produce measurably better results.
This doesn't mean the internal organization should sit by idly while the "experts" come in and do their magic; just the opposite. The best initiatives seem to be built on combined teams using a mix of internal leaders who've been freed up from their day-to-day tasks, coupled with external experts who have prior experience in key areas.
The last topic bears some special discussion -- finding a place to start. The natural tendency is to think that everything has to move ahead simultaneously. Or thinking you can't make forward progress in a few areas without having a good solution for the massive legacy that's all around you.
The best advice I can offer is simple: find the part of the organization that's most critical of the current IT function, and point the new capabilities at their requirements.
Frequently, your loudest critics are the ones trying to use internal IT capabilities to enter new markets, create new sources of revenues, deliver better customer experiences and the like. No harm in reaching out to these typically underserved IT users, and building a better world for them :-)
Phase Three Discussion -- Accelerating The Journey
At this point of the IT leadership conversation, we're now in the downhill stretch. We've hopefully done a decent job in helping them think about their specific case for cloud and IT transformation. And we've shared our experience around the tough bits of the journey, and what we see people doing about it.
Now the conversation turns to getting their sooner than later. And we're asked for advice in that area. Every answer is different, but -- generally speaking -- we tend to talk about four concepts in general.
The first is the notion of establishing a transitional leadership team. Current org structures are usually designed for business-as-usual vs. leading a significant transition.
The leadership team, in turn, can start to figure out approaches to the laundry list of issues I shared above. The more horsepower you can put on this team, the faster things will happen.
The second is the new concept of pre-integrated infrastructure. We use the VCE Vblock as an example, but others can be considered. These newer offerings force a mindset change in IT organizations -- from building infrastructure to actually using it.
Experience has shown that investing less in hand-crafting the plumbing means more time spent in other more productive areas. It also sends a powerful message to everyone that, yes, things are changing :)
The third is to make an initial and highly visible investment in a new training curriculum around the new skills. EMC has offerings in this area (e.g. cloud architect), but there are others. This pays two dividends: it starts to build the required skill sets you'll need for the journey, in addition to sending a powerful message to the organization.
The fourth is to find a few consultants or vendors who you can trust. The usual keep-everyone-at-arms-length mentality will inevitable slow progress forward, e.g. making everything go through a standard RFP and procurement process.
Of course, EMC would like to be considered as a candidate for that special relationship.
Assuming The Leadership Mentality
In the aftermath of this end-to-end dialog with senior IT leadership, there's an unspoken challenge on the table: there's probably an opportunity for significant leadership in front of you -- will you take it, or pass?
Every situation is different. The challenges might be too formidable, the case not compelling enough, or the key people involved are just not in a situation to move forward for whatever reason.
That's the world we live in.
But -- after going through this -- it's more often the case that there's a spark of enthusiasm in people's eyes. They really want to move things forward. They can see how this all might happen. And they're willing to assume a much stronger leadership role to make it happen.
And that's a good thing when it happens.
Nice blog piece
Posted by: Ron Livesey | February 12, 2011 at 02:18 PM