Transcript of a sponsored BriefingsDirect podcast discussion on properly developing a strategy for cloud computing adoption.
Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Learn more. Sponsor: Hewlett-Packard.
Free Offer: Get a complimentary copy of the new book Cloud Computing For Dummies courtesy of Hewlett-Packard at www.hp.com/go/cloudpodcastoffer.
Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect.
Today, we present a sponsored podcast discussion on properly developing a roadmap to cloud computing adoption in the enterprise. The popularity of the concepts around cloud computing have caught many IT departments off-guard.
While business and financial leaders have become enamored of the expected economic and agility payoffs from cloud models, IT planners often lack structured plans or even a rudimentary roadmap of how to attain cloud benefits from their current IT environment.
New market data gathered from recent HP workshops on early cloud adoption and data center transformation shows a wide and deep gulf between the desire to leverage cloud method and the ability to dependably deliver or consume cloud-based services.
So, how do those tasked with a cloud strategy proceed? How do they exercise caution and risk reduction, while also showing swift progress toward an "Everything as a Service" world? How do they pick and choose among a burgeoning variety of sourcing options for IT and business services and accurately identify the ones that make the most sense, and which adhere to existing performance, governance and security guidelines?
It's an awful lot to digest. As one recent workshop attendee said, “We're interested in knowing how to build, structure, and document a cloud services portfolio with actual service definitions and specifications.”
Well, here to help us better understand how to begin such a responsible roadmap for a cloud computing adoption we're joined by three experts from HP. Please welcome with me, Ewald Comhaire, global practice manager of Data Center Transformation at HP Technology Services. Welcome, Ewald.
Ewald Comhaire: Hi, Dana.
Gardner: We're also joined by Ken Hamilton, worldwide director for Cloud Computing Portfolio in the HP Technology Services Division. Welcome, Ken.
Ken Hamilton: Thanks. It's great to be here.
Jagger: And, we're also joined by Ian Jagger, worldwide marketing manager for Data Center Services at HP. Welcome, Ian.
Ian Jagger: Hey, Dana. Equally happy to be here.
Gardner: Cloud is an emerging and, frankly, a huge phenomenon driven, I think, by economics and the need for business transformation, as well as new IT service delivery capabilities. I wonder what implications this has for IT leaders. They're in the trenches, so to speak, and they are trying to make cloud happen. Ewald, how are these folks reacting right now?
A new benchmark
Comhaire: Independent of how we define cloud -- and there are obviously lots of definitions out there -- and also independent of what value cloud can bring or what type of cloud services we are discussing, it's very clear that the cloud service providers are basically setting a new benchmark for how IT specific services are delivered to the business.
Whether it's from a scalability, a pay-per-use model, or a flexibility and speed element or whether it's the fact that it can be accessed and delivered anywhere on the network, it clearly creates some kind of pressure on many IT organizations. The pressure really comes from three different angles.
The first one is, whether IT organizations should allow their businesses to consume directly those cloud services without any control by IT. Or, should IT basically build up some, what we call, service brokering capabilities, where they can select the cloud services that are of value to the company. Then, maybe they wrap some additional value around them and then offer those through the business, with IT being basically the broker of these capabilities.
The second pressure is, if you don't want it to be outsourced, should you compete and compare yourself to a cloud service provider and transform your own internal IT operations to function more like an internal type of cloud with the same benchmarks on flexibility, scalability and what have you.
Third, of course, is that you will not have everything in the cloud, and some companies may also think about becoming a cloud service provider themselves. This is the third element, if your company requests you to play a role in becoming a cloud service provider. How, as an IT organization, do you support that request coming from the business?
So, all in all, there are quite a few questions that the businesses have about their IT organization, which then lead to our recommendation that the company should think about building out the cloud strategy.
Gardner: I'm curious, Ewald. Is this something new in terms of how they approach the problem or are there some precedents that they can go? Perhaps there are procurement precedents and how they secured partners or vendors in the past, outsourced in the past, or if they've done any work with software as a service (SaaS). Where do they start in terms of looking to the past in order to leapfrog into the future?
Comhaire: There are some things that are unique about the cloud. First of all, in the cloud, everything is about the service first, and then the technology will follow the service. That's something that companies will have to think about.
First, think in terms of the services they want to deliver and then fill in those services with the right technologies that achieve the goals of the service. Some companies may already have quite some expertise there. For example, they may have started to build an internal shared services environment, which may already have that service-oriented thinking behind it, but architecturally their services may not have reached the attribute that a typical cloud service has.
Working on the architecture
These companies will have tremendous benefits on the thinking model, the organizing for a service centric delivery model, but they may need to just work a little bit on the architecture. For example, how can they address scalability and the way that supply and demand are aligned to each other, or maybe how they charge back for some of these services in a more pay-as-you-go way versus an allocation based way.
These companies will already have a big head start. Of course, if you're working on an internal cloud, have things like virtualization in place, have consolidated your environment, as well as putting more service management processes in place around ITIL and service management, this will benefit the company greatly. We'll want to have the cloud strategy rolling out in the near future.
Gardner: Now, I'm aware that HP is doing quite a bit of work around cloud. I wonder what you are finding in the field, as you talk to these customers. Ian, what are some of the top reasons that you are hearing from these folks as they're trying to educate themselves, and grapple with this transition? What are the top reasons that you are seeking to do this in the first place?
Jagger: That's an interesting question, because I think the pressure is coming from two sides. One is from the business side in terms of what cloud means for the business, how a business can become more competitive and take a leading gain within the marketplace in which they operate. From the IT side, there is a required reaction of being proactive about looking at what cloud is all about and how cloud can bring advantage ultimately through the business.
So, there are two thoughts. One is that the business wants to gain a competitive advantage, and two, it is up to IT to do something about that. As Ewald was just saying, it could be that the business is already reaching out to services that are within the cloud and accessing those services. There is an onus on IT for them to keep their own shop in order and become the provider themselves of those services as a service.
Gardner: And, if they're looking for this increased agility, I suppose that also would cut out the need for a lot of upfront capital expenditures. It seems that in a down economy you'd want to be able to be agile, but without having to go through a long budget process and jump through a variety of hoops in order to get the funding. I suppose the pay-as-you-go model makes some sense, now more than ever.
Jagger: That's right, and it certainly does cut out some hurdles. If there are critical applications that you seek for your business, and they're available through the cloud, either from a service provider or through the shared services model that Ewald talked about, that's going to be far more efficient and cost-effective, subject to ... terms of the pay-per-use and security. But, once security is addressed, there are definite cost and efficiency advantages.
Gardner: Ken, we've heard for a number of years about the need for agility, something that's not necessarily new and I am sure won't go away. We'll be hearing about the need for agility 10 or 20 years from now. But, are there any specific business drivers for this interest in cloud, any business outcomes that people most frequently expect to happen as they move toward this model?
Hamilton: As we pointed out, we're seeing a growing interest in cloud specifically around cost savings. Certainly, in this economy, cost savings and switching from a capital-based model to an operational model, with the flexibility that implies, is something that a number of companies are interested in.
But, I'd also like to underscore that, as we've discussed, the definition of cloud and the variety of different, and sometimes confusing possibilities around cloud, are things that customers want to get control of. They want to be able to understand what the full range of benefits might be. The major ones we see right now are underscored by cost savings and financial flexibility in going from a capital-based model to an operational model.
By the same token, we're finding that they're also interested in exploring far-reaching benefits. As Ewald pointed out, some companies who have not traditionally been in the “technology business,” may find that cloud offers them the opportunity to be able to change their business model.
We're dealing with a couple of telecommunications providers, and even some financial institutions in Asia Pacific Japan (APJ), who are looking cloud as an opportunity to be able to expand their market and to be able to take on new capabilities, in addition to some of the economies of scale that come out of this.
In addition to that, we touched on faster time to market and agility. In a typical internal environment it may take weeks or months to deploy a server populated in a particular fashion. In that same internal cloud environment that time to market can be as little as hours or minutes, along with some of the increased functionality.
So, cost savings as well as agility and new business capabilities really are the three main types of benefits that we are seeing customers go after.
Gardner: Ken, doesn't this in some ways fundamentally shift the role of IT? It seems, based on what you just said, that IT's role is now about betting on those who are supplying services, perhaps crafting a service-level agreement (SLA) or even getting at the contractual negotiations and then monitoring the quality of those services.
Is that a different role for IT? In the past, they would have simply defined requirements and then delivered the services themselves.
Hamilton: I wouldn't say it's a different role, but rather a greatly enhanced role. IT does procure services today and does a fairly decent job of it. Because of the service orientation, this puts a greater emphasis on understanding not just the technological underpinnings, but the contractual service level elements and the virtual elements that go with this.
A number of implications
As we know, virtualization is a big part of this, but when virtualization comes into play, there are a number of different implications for the service structure, availability, security, risk, and those types of elements. So, there is a greater emphasis today in terms of laying those out, defining them, and procuring the right structure to be able to meet their specific business needs.
Gardner: I suppose their concern, then, is defining the requirements and then measuring the outcome, rather than being concerned what that middle phase would be -- how you actually do it. Is that fair?
Hamilton: Right. If there is a big shift, it's moving from the orientation of a physical infrastructure, dealing with the products, and then delivering that as their service to a grouping of capabilities with service levels, particularly involving external service providers in that level of reliability or acting as an external service provider. So, there is a greater level of expectation on the part of customers for that level of service delivery.
Gardner: Going back to the market data that we've gathered through these HP workshops on cloud adoption and data-center transformation, Ewald, as folks now start to proceed in this direction toward cloud model, recognizing some shifts, looking for those agility and monetary benefits, what's holding them back? What do they say are their top inhibitors from pursuing that?
Comhaire: Dana, that's a very interesting question. We often talk about all the benefits, but obviously, specifically for our enterprise customers, there's also an interesting list of inhibitors. In every workshop that we do, we ask our participants to rank what they believe are the biggest inhibitors, either for themselves to consume cloud services or, if they want to become a provider, what do they believe will be inhibiting their potential customers to acquire or consume the services that they are looking for? Consistently, we see five key themes coming as major inhibitors.
The first one is about the loss of control. That means I am now totally dependent on my cloud-service provider in my value chain. A lot of companies have value chains that they've built, but what if some of the parts of that value chain are in the cloud? Have I lost too much control? Am I too much dependent?
There are some interesting stories that are absolutely real. A satellite service provider, for one of its key component in bringing the television signals to your home, was relying on a cloud service provider that was taken over by one of their competitors to that satellite company.
As a result, suddenly there were interruptions in the service quality and, of course, this leads into the reality that there could be a loss of control if you have parts of your value chain out in the cloud. That's a real concern, not a perceived one.
Also, there is lack of trust in your cloud service provider. That could have to do with the question of whether they'll still be in business five years from now, and will I have to take back control, if they go out of business. We know that this existed in the dot-com world and cost the companies a lot of money by bringing it back in-house when the provider went out of business.
It could also have to do with the things like price-hikes. What guarantees for me, for example, that the price of a CPU per hour wouldn't double, once the provider has achieved a big enough critical mass. They can decide to double the cost at any moment in time.
Security and vulnerability
Another area that's called out frequently is the whole security and vulnerability case. Some of that is perceived. If you architect it well, best-practice cloud-service providers can do a great job of actually being more secure than a traditional enterprise dedicated environment.
But, still, there are some things that are more difficult to control. For example, you become more vulnerable to attacks, when you are on the Internet. A well-known service provider becomes a natural source of all kind of attacks. Of course, that's more difficult to prevent architecturally. It's something you will have to deal with as a cloud service provider, and something that consumers will have to take into account.
There are also difficulties around identity management and all of the things to integrate security between the consumer and the provider that are an additional complexity there.
Confidentiality is the fourth reason and mostly concerning the data, because, more and more, the data goes with the service. What guarantees do we have, for example, that an employee at a service provider can't take that data and sell it to a government or some other third party.
Also, data has to go over the network. There is always a risk of interception and there is always a risk, if you have a multi-tenant environment, that somehow, through an operation error, some data that should be confidential is exposed to another party. That is definitely a concern for a company.
The final one is reliability -- is the service going to be up enough of the time? Will it be down at moments that are not convenient? I go back to the example of the satellite company. What if the downtime is only five minutes but it's always at 8 p.m., the prime time of satellite television? It may only be five minutes, but it can take you an hour to recover, and it's coming at the most inconvenient moment.
So, this whole reliability concern and disaster recovery is obviously a key element, along with one that comes out more and more in recent workshops: How do I integrate with the cloud?
That is, if I need to make a little change in the business process, with an application in the cloud, can the cloud-service provider make that change? How can I process integration in such a distributed world? That gets a little bit more difficult than in a more traditional enterprise architecture.
Gardner: I hope that a lot of the cloud providers are listening, because it seems like they have quite a workload to overcome some of these issues around security and control. I was a little bit surprised not to hear that issues about standards and neutrality weren't in the top five or six. Do you perceive them as being a little bit lower or do they perhaps fall into these areas of security and confidentiality?
Standards and integration
Comhaire: That's a great question, Dana. They definitely fall in the category of integration, because if the cloud service provider has done everything in a unique way, it's still of great value, a great quality of service, and maybe with a great cost, but it's difficult to integrate the cloud service due to its not following certain standards or being difficult to integrate with the standards that already at the enterprise inside of their data center, then obviously you get this integration difficulty. So, standards and integration difficultly are the same issue expressed in different terms.
Gardner: I wonder if either Ken or Ian has any further points that they've observed in the field about inhibitors. What's holding customers back as they pursue cloud adoption?
Hamilton: I'd just underscore the concerns with security. Particularly in a multi-tenant environment, that seems to be the number one issue that the customers are concerned with. So, first is security, and number two would be reliability. There have been some large failures of some top-named cloud providers. I think they're getting better, but still not quite ready for prime time in some cases.
Gardner: Ian, any thoughts?
Jagger: I'd probably just add to that, not just from the IT side in terms of security, but also from the business side in terms of trade secrets. If you're a provider of cloud services, you know you have that application on there and you have got it out through cloud, which is the great business model you've used to get to market itself. But, how secure are my trade secrets with doing that, and also with respect to addressing to national privacy laws as well. There are some issues that need to be taken into account.
Gardner: Ken, let's go back to you. As customers need to get better informed and to lay out their roadmap, what options do they have? Perhaps you could tell us what would you try to offer them as a way to get started?
Hamilton: Well, the first, and the most important thing, is to make sure that the executive decision makers have a common understanding of what they might want to achieve with cloud. To that end, we've developed a Cloud Discovery Workshop, which is really a way of being able to frame the cloud decision points and to bring the executive decision makers together.
They can have a highly interactive discussion around what key business objectives they might have and what risks and opportunities there might be, many of which we've covered already. It's also to make sure that the organization is crystallized around their specific areas of opportunity and benefit, as well as the specific risks and investments that might be required to focus on this customized view that they have.
This Cloud Discovery Workshop does a great job of engaging the executive team in a very focused amount of time, as little as an afternoon, to be able to walk through the key steps around defining a common definition for their view of cloud. It's not just our view or some other vendor's view, but their definition of cloud and the benefits that they might be able to accrue.
They, specifically drill that down into particular areas with a return on investment (ROI) focus, the infrastructure capabilities that might be required, as well as the service management operational and some of the more esoteric capabilities that go hand in hand, addressing security, privacy, and other areas of risk. It's just making sure that they've got a very clear way of being able to document that, and then move forward into more detailed design, if that's the direction they want to move in.
Gardner: Ewald, you mentioned earlier that those shops that have adopted service performance and IT shared services activities have a bit of a head start, but for them or others? What sort of roadmap process do you offer or recommend?
A better view
Comhaire: From the workshop customers basically get a better view of the strategy they want to go for. We have an initial discussion on the portfolio and we talk also a little bit about the desired state. In the roadmap service, we actually take that to the next level. So we really start off with that desired state.
We have defined the capability model with five levels of capability. We don't want to call it the maturity model, because for every company, the highest maturity isn't necessarily their desired state or their end state. So, it's unfair to name it "maturity." It's more a capability or an implementation model for the cloud. We have five levels of maturity and then six domains of capabilities.
The first thing we determine is an appropriate next state to put as an objective. If you want to become a cloud-service provider, but you haven't done the initial service enabling in your company, you have to go through this intermediate route. You need to say, "First, I will start to build something like an internal shared service that starts bringing technology together and delivering it as a service internally, before I step into the outside market."
So, you first build credibility within your own business, before you actually build credibility in the market. That could be a very logical step on the roadmap. That's Module 1 -- helping customers determine the next desired state on the roadmap and then the end state.
Module 2 is really about, "We know where you want to be now. Let's get more in detail about what projects we need to execute to get to there? What are the gaps? What resources are needed and what skills of resources do you need?"
In the cloud, you may have new roles, like a service delivery manager. The role of a capacity manager is totally different in the cloud than in the non-cloud. In the case of the cloud, the capacity manager will need to make decisions to acquire new assets to grow the business. They can't go to a finance manger. The process would take way too long and the scalability would not be there corresponding to a cloud model.
So, the roles are different. We look at how many people you need, in what roles, with what descriptions and what capabilities. We also look at the timing of what to do when, what the dependencies are of other parts of the organizations, and how to phase that in over a timeline. This is typically what Module 2 is.
Module 3 of the roadmap is then, "We now know where we want to be. We have a good idea of the gaps, the projects that need to be done, the resources, and their skills. How do we sell it to the company and how do we present our conclusion to an executive board or to the executives in the company?"
It's how do we build a business case and how we present that business case financially, value wise, and strategy wise through the corporation. That's really the three components of our roadmap service that then can lead into a cloud design and an implementation activity later on.
Gardner: I imagine of any transformative activity that this is a multi-year process. On that roadmap, do you have any timeline that gives us a rough sense of how quickly these organizations can get to the cloud, or should they not try to rush things?
Keep it simple
Comhaire: One core advice we always give is, "Keep it simple." Rather than bring out a whole portfolio of cloud services, start with one. And, that one service may not have all the functionality that you're dreaming of, but become good at doing a more simplified things faster than trying to overdo it and then end up with a five- or six-year's project, when the whole market will be changed when you can roll out. A lot of the best practice in building the roadmap is to simplify it, so it does not become this four- or five-year project that takes way too long to execute.
Gardner: Well we are just about out of time. I hope we could go around the group and get your impressions on how to get started or any specific areas that people could go to for further information or deeper background. Let's start with you, Ian. Where do people get started, and how should they proceed?
Jagger: I think they should talk to somebody like Ewald. That would be a great start.
But I would probably just like to add, Dana, that what we talked about here is simplifying what cloud is about for the customer, ignoring to an extent how the industry itself is defining cloud definitions. We're looking at this in three ways: do you want to be a service provider, do you want to source cloud, or do you want to build your own shared infrastructure on a private cloud.
And, we've just been talking about roadmap. You actually have the options of being any or all of the above. You can do all three of them. Your business model could be as a cloud service provider. Your sourcing model could be from an outsourcing perspective. What you're not outsourcing, you may actually prefer to build as a shared services internal model.
You need to determine what your priorities are. I'm not being facetious when I say talk to Ewald. Ewald's team of guys, are absolutely the correct start point. But your local HP firm sales representative would also be an ideal start.
Gardner: Alright. Ken Hamilton, your ideas about first steps.
Hamilton: I would really underscore what Ian has just said. Keep it simple. Make sure that you've got a very good team understanding of what it is that you want to get done, and leverage experts. We have Ewald and a number of highly qualified people in each of our regions. We just really want to keep it simple, understand what it is that you're trying to get done and leverage the expertise of people who have done it in the past.
Gardner: Quickly back to you, Ewald. I keep hearing the word cloud computing, but if we were to interchange services-oriented architecture (SOA), it would probably just as accurate. Is there a commonalty now between the two?
Comhaire: There have many things in common. I would still argue that there are also some differences. A cloud's architecture will be using an SOA as its underlying fundamental, but the composability of an SOA is not just in how you design the application.
It also has to do with how the services in your cloud can be used together to achieve a bigger integration. That's not just at the level of the application, but it's also the IT services themselves. Are they composable and can they be combined to achieve a bigger thing than just the one service and its value as a standalone item?
Gardner: Thanks so much. We've been discussing some of the ways in which IT organizations and enterprises can move towards cloud and reduce risk, but perhaps accelerate attaining the business benefits of an "Everything as a Service" world. Here to help us with this, we've been joined by Ewald Comhaire, global practice manager, Data Center Transformation at HP Technology Services. Thanks so much, Ewald.
Comhaire: Thanks, Dana.
Gardner: We've also been joined by Ken Hamilton, worldwide director for Cloud Computing Portfolio within HP Technology Services. Thanks to you too, Ken.
Hamilton: Thank you, Dana.
Gardner: And Ian Jagger, worldwide marketing manager for Data Center Services at HP. Thank you, Ian.
Jagger: My pleasure, Dana.
Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You have been listening to a sponsored BriefingsDirect podcast. Thanks for listening, and come back next time.
Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Learn more. Sponsor: Hewlett-Packard.
Free Offer: Get a complimentary copy of the new book Cloud Computing For Dummies courtesy of Hewlett-Packard at www.hp.com/go/cloudpodcastoffer.
Transcript of a sponsored BriefingsDirect podcast discussion on properly developing a strategy for cloud computing adoption. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.