It's an increasingly common scenario with our customers.
Senior IT leadership wants to transform a traditional IT organization into a more cloud-like IT service provider. They know it's important, and there's a sense of urgency.
But there's a real cloud of thorny issues swirling around.
What's the potential opportunity? How ready are we? What stays internal, and what would be better off run externally? What changes do we need to make to achieve the potential?
And -- more importantly -- how do we start making progress towards our goal?
A while back, EMC Consulting rose to the challenge, and started to offer a suite of Cloud Advisory services around these themes. Customer feedback has been extremely positive.
And, with this post, I wanted to share with you some highlights of what we've learned over multiple engagements.
Why Outside Help Is Useful
I work with many, many bright and very capable IT organizations as part of my role at EMC. Certainly, they have the capability to do most anything themselves if they set their mind to it.
I joke that when my wife wants something important done around the house, she calls a professional instead of asking me to do it. The results are always better, and it gets done faster.
The same logic applies here: when you engage with someone who's done something complex before, you get the benefit of not only their expertise, but their professional detachment.
Not that any IT organization would find it hard to see the forest for the trees :)
EMC Consulting has established a good reputation for itself by delivering short, impactful and time-bounded engagements. They get in, get the job done, and get the heck out. If you do well at what you've been asked to do, you will inevitably be invited back to do more.
Breadth And Depth
When a large IT organization is considering a strategic shift in how they do IT, there can be a lot on the table. You name it, and it's up for extended and emotional debate.
Unfortunately, the unique nature of these "turning point" issues can vary considerably from client to client -- so there's no easy or repeatable recipe that works the same for everyone.
The challenge is to bring consultants that can quickly assess the big landscape, and gain consensus on what those few core issues might be for a particular situation, and then spend the needed time to drill down hard on those particular concerns.
For this particular engagement, it turns out that most everything hinged around (a) getting governance right (what stays and what goes), and (b) untangling the IT finance model.
As you can see from the overview slide, though, it's important to take one pass broadly at the outset.
From Current State To Future State
Well, yes and no. There's usually a plethora of anecdotal knowledge, but sometimes clinical assessments, well-summarized, are hard to come by.
In larger environments, though, you can can spent many moons running around and assessing things.
The shortcut, as we've discovered, is to select a handful of proxies -- candidate workloads that are both representational and relatively finite.
The sample, if reasonably constructed, should serve as a good-enough proxy for the remainder of the IT environment.
Articulating Future State
For the vast majority of clients, there's strong logic to envision a dynamic mix of internally provided and externally provided resources.
We use the term "private cloud" to apply to cloud-like IT-as-a-service delivered by the IT organization, "public cloud" to apply to XaaS offerings generically available to everyone, and "hybrid cloud" to refer to the combination of both.
Here's the attention-grabbing headline: our experience so far has shown the potential of 20%-30% total IT cost savings by using an optimized blend of both.
If your aggregate IT budget is in the hundreds of millions (or sometimes billions) of dollars, that's a big pot of gold to consider seriously.
That's the potential -- but how do you make the case for getting there?
What Are The True Costs?
In any decent IT-as-a-service environment, you've got a clear and granular view of cost-to-serve: for a particular function: what is the all-in, fully-allocated cost for function XYZ?
Unfortunately, IT finance can often get quite byzantine.
Costs show up all over the place -- sometimes in IT, sometimes at corporate, sometimes in the business unit -- and untangling all that spaghetti in a reasonable manner can be a complicated challenge, not to mention occasionally political.
But, to get a clear picture of the current state costs to deliver IT services, that's exactly what needs to be done.
Again, what EMC Consulting has figured out is how to do that reasonably well for a subset of workloads.
The results can generate some "aha!" moments. Understanding your current cost-to-serve means that you can make a reasonable comparison against alternative scenarios.
And What Are The Business Drivers?
It's blindingly simple, but often overlooked by technologists: IT ultimately exists to create business value vs. simply contain costs.
As a result, an essential part of the EMCC engagement is to map critical business drivers back to the proposed IT initiative.
As you can see from this client-specific chart, the left side has some pretty heavy strategic topics, e.g. supply chain collapse, emergence of virtual companies, etc.
That being said, it's not too difficult to establish clear linkages between those weighty concerns and the prospective advantages of the new environment.
As a result, the "justification equation" for any client's cloud strategy is actually two components. One -- doing what you're doing today, only better -- more efficiently, more reliably, etc. And two -- set the stage for doing new things that the business needs done -- agility, if you will.
The "Cloud Screen" Approach
This particular part of the methodology has turned out to be quite useful indeed.
Each workload is screened through three distinct filters.
The first is simple economics -- can the given workload be run meaningfully cheaper using external services, or a combination of internal and external cloud?
You might be surprised to learn that many workloads are currently *more expensive* to run on external services when all costs are factored in.
However, this isn't a static situation; new services (and associated costs) are being made available to enterprise IT organizations on almost a daily basis, so the methodology itself (vs. the results) has great value.
The second filter is trust -- is there enough trust in a given external service to move a candidate workload? "Trust" involves more than simple compliance with security, governance, etc. -- it involves the perspectives of the function or process owners.
And, once again, perspective around trust are dynamic in nature: what might have been unthinkable a year ago might be approachable now. Another reason why the methodology is useful -- it'll be something you'll want to do periodically.
The final filter, not surprisingly, is functionality -- does the external service do what's required, given that there is an economic advantage and sufficient trust exists for the function? Again, another moving target …
Yes, it's a simplistic analysis, but that's the point -- it's relatively easy for IT leaders to get their heads wrapped around the internal vs. external opportunity. More drill-down (including evaluating tradeoffs) needs to be done, but it's an excellent stating point.
Getting The Mix Right
You might assume that, for each workload, it's a binary proposition -- either a workload should run in an external service, or it should run internally. Our experience has shown otherwise -- it's getting the mix right at the per-function level.
As a hypothetical example, let's take messaging.
Perhaps the internal private cloud function is competitive for delivering production Exchange servers, but what about long-term archiving and compliance? Would that be better consumed as an external service? Or how about DR for the messaging environment?
The picture that emerges for each function is similar -- they're each composed of sub-function, each of which in turn is a candidate to be done internally on a private cloud, externally on a public cloud, or -- more typically -- a thoughtful combination.
The Path Forward
Every engagement so far has been reasonably prescriptive about the path forward, although delivering a detailed execution plan for cloud enablement is usually thought of as a discrete engagement vs. creating the case for doing so.
At a summary level, an end-state concept model is presented. Before you reject simplistic diagrams out-of-hand, I would like to point that they go a long way to helping a broad swath of people understand the discussion.
We also invest time to make sure the client understands that any cloud-like IT-as-a-service approach is fundamentally different than traditional physical IT.
This is not an effort to sell the benefits of cloud per se, but simply an effort to help the client understand how far-reaching the differences can be.
A Suggested Five Phase Conceptual Model
Although methodologies might vary, a good starting point for the discussion is the five-stage model that EMC Consulting uses for accelerated programmatic transition vs. organic IT evolution.
Consolidation might seem like an awkward starting point, but in many larger IT environments, IT is dispersed between many locations, many functions and many groups. You need control of a decent-sized chunk of the IT landscape to make any serious progress.
Hence a "phase 0" recommendation around simply physical and/or logical consolidation. More often, this has to do with lines of responsibility and authority than anything else.
Abstraction might be seen as a more general example of virtualization, but here it's applied to all the resource layers: compute, network, storage, etc. Here the parallel agenda is for rampant and ruthless standardization in both technology and process.
Once the processes and workflows are understood in the new model, it's time for automation. In addition to reducing the obvious labor costs, speed and agility increases dramatically, as well as reduced errors through manual processes. Trying to automate processes that haven't been re-engineered for IT-as-a-service is an exercise in futility in my humble perspective.
Once the back end is humming along nicely, it's time to open up the front-end by creating utility consumption models, with an emphasis on self-service on-demand consumption. This also is where users become acutely aware of the resources they're consuming through either show-back or other cost transparency mechanisms.
Finally, once the business is accustomed to consuming services (vs. individual puddles of technology), the move to federate and optimize the internal/external mix can begin seriously. Processes have matured, perspectives and behaviors have changed, and now it's a much more pragmatic discussion.
There's a natural and sequential logic here that applies in many "accelerated transition" situations: consolidate to gain control, abstract logical from physical, automate the new processes and workflows, expose new service consumption models to the business, and optimize the mix of how those services are provided.
Easy To Say, Hard To Do
One of the more useful constructs that EMC Consulting has brought to the table is the notion of a "cloud program management office". The transformation to IT-as-a service can be a long journey that involves not only most of IT, but most of the business as well.
As with any sustained transformational effort, it's going to take some serious planning and effort.
This chart shows the usual workstreams that are involved: from strategy to infrastructure to management to deployment to communication and engagement -- there's a lot of moving pieces involved.
Remember, the goal here is not to dissuade IT organizations from going on this journey, but rather to prepare them for what inevitably lies ahead.
Despite the apparent simplicity of this chart, it masks some very serious discussions. For example, retraining the business to consume IT intelligently. Or the shift to new skills and roles, and managing the transition to a new IT organizational model. Or perhaps re-engineering the IT finance model.
Or maybe establishing a governance model that's based on facts vs. aggregated opinions ...
Another cut is the "people, process, technology" view. As part of our once-through, we inevitably come up with some solid perspectives around not only current organizational readiness, but key areas where changes will need to be made.
To be clear, we make every effort to avoid the typical consulting double-speak, and put our findings in clear language that's relatively easy to navigate. That being said, these sorts of transformations are relatively complex initiatives, so there's a lot to discuss as an integrated whole.
And, finally, every situation is different. Please don't take these examples as applicable to your specific circumstances.
That being said, I think it's useful to see what pieces of the final analysis might look like.
Beware The "Cloud Is Easy" Pitch
Maybe cloud can be easy for end users, but that's certainly not the case for most IT shops.
Vendors, in their efforts to sell you their wares, will inevitably make their offers look incredibly simple and effortless. Sure, we as vendors can make the technology bits relatively easy -- unfortunately, the real heavy lifting involves how the organization uses the technology.
One of the reasons I continue to be a big fan of pre-integrated single-support infrastructure stacks (e.g. VCE Vblock) is that it minimizes the traditional focus on selecting, integrating and supporting infrastructure, and puts the spotlight squarely on the required organizational changes -- both inside and outside of IT.
As a long-time employee of EMC, I'm personally very pleased that we've invested in understanding the real challenges associated with IT transformation, and are prepared to offer meaningful consulting services -- either alone, or with our partners -- to help IT leaders accelerate through this inevitable industry transition.
Because, at the end of the day, cloud is really about transforming how IT is done.
Comments