Monday, October 26, 2009

Linthicum's Latest Book: How SOA and Cloud Intersect for Enterprise Productivity Benefits

Edited transcript of BriefingsDirect Analyst Insights Edition podcast, Vol. 45 with consultant Dave Linthicum on the convergence of cloud computing and SOA.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download a transcript. Charter Sponsor: Active Endpoints. Also sponsored by TIBCO Software.

Special offer: Download a free, supported 30-day trial of Active Endpoint's ActiveVOS at www.activevos.com/insight.

Take the BriefingsDirect middleware/ESB survey now.

Dana Gardner: Hello, and welcome to the latest BriefingsDirect Analyst Insights Edition, Volume 45. I'm your host and moderator Dana Gardner, principal analyst at Interarbor Solutions.

This periodic discussion and dissection of IT infrastructure related news and events with industry analysts and guests, comes to you with the help of our charter sponsor, Active Endpoints, maker of the ActiveVOS and visual orchestration system, and through the support of TIBCO Software.

Our topic this week on BriefingsDirect Analyst Insights Edition, and it is the week of Oct. 12, 2009, centers on Dave Linthicum's new book, Cloud Computing and SOA Convergence in Your Enterprise: A Step-by-Step Guide. We're here with Dave, and just Dave this time, to dig into the conflation of SOA and cloud computing. Welcome back to the show Dave.

Dave Linthicum: Thank you very much, Dana, thanks for having me.

Gardner: Congratulations. I know producing books like this is bit a like gestating and giving birth, so it may be as close as we guys can come to that experience.

Linthicum: Yeah. I'm already having postpartum depression.

Gardner: So, you’re out with a new arrival and this is part of the Addison-Wesley Information Technology Series.

Linthicum: That's right. It's my fourth book with those guys, starting with the EAI book back in 1997.

Gardner: But, that's still moving off the shelves, right?

Linthicum: It sure is.

Gardner: When is the latest book available? How can you get it and what is it going to set us back?

Linthicum: Cloud Computing and SOA Convergence for Your Enterprise is available now. You can get it on Amazon, of course, for $29.69, and there is a Kindle edition, which, I'm happy to say, is a few bucks less than that. And, I've even seen it on Buy.com for $26. So, get your best deal out there.

Gardner: For those of our listeners out there who might not be familiar with you -- and I have a hard time believing this -- why don't tell us a little bit about yourself and your background, before we get into the timely tome that you've now developed?

Where Web meets enterprise

Linthicum: I've been a distributed-computing guy for a number of years. I've been a thought leader in this space, including writing the EAI book, which we talked about, back in 1997. I was CTO of Software AG, it was called SAGA then, and also CTO of Mercator, and then CTO of Grand Central.

I was CEO of a company called Bridgeworks and then founded my own consulting company called David S. Linthicum, LLC and ran that for any number of years.

I'm primarily focused on where the Web meets the enterprise and I've been doing that for the last 10 years. As the Internet appeared on the scene, I realized that it's not only just a great asset for information, but a great asset where you can put key enterprise applications and post your enterprise data.

There are lots of reasons -- economies of scale, the ability to get efficiency in reuse, the ability to rapidly provision these systems, and get out of the doldrums of IT, which a lot of companies are in right now.

Cloud computing has the opportunity to make things better. The purpose of this book is getting people to look at that as an architectural option for them. In the book, the step-by-step guide provides them with steps that it takes to understand your own issues, your own information, your own data, and your processes, and then figure out the right path to the cloud.

Gardner: It seems that cloud has also, just in the nick of time, come along to give service-oriented architecture (SOA) a little bit of a boost and perhaps even more meaning than people could conjure up for it before.

Linthicum: SOA is the way to do cloud. I saw early on that SOA, if you get beyond the hype that's been around for the last two years, is really an architectural pattern that predates the SOA buzzword, or the SOA TLA.

It's really about breaking down your architecture into a functional primitive, or to a primitive state of several components, including services and data and processes., Then, it's figuring out how to assemble those in such a way that you can not only solve your existing problems, but use those components to resolve problems, as your business changes over time or your mission changes or expands.

Cloud computing is a nice enhancement to that. Cloud doesn't replace SOA, as some people say. Cloud computing is basically architectural options or ways in which you can host your services, in this case, in the cloud.

As we go through reinventing your architecture around the concept of SOA, we can figure out which components, services, processes, or data are good candidates for cloud computing, and we can look at the performance, security and governance aspects of it.

Architectural advantages

We find that some of our services can exist out on the platform in the cloud, which provides us with some additional architectural advantages such as self-provisioning, the ability to get on the cloud very quickly in a very short time without buying hardware and software or expanding our data centers, and the ability to rapidly expand as we need to expand basically on demand.

If we need to go from 10 users to 1,000 users, we can do so in a matter of weeks, not having to buy data-center space, waves and waves of servers, software, hardware licenses, and all those sorts of things. Cloud computing provides you with some flexibility, but it doesn't get away from the core needs to architecture. So, really the book is about how to use SOA in the context of cloud computing, and that's the message I'm really trying to get across.

Gardner: For some folks, the SOA adoption curve perhaps didn't grow as fast as many expected, because the economic impetus was a bit disconnected. Perhaps, it was too far in the future to make direct connections between the investments you would make in your SOA activities and the actual bottom line of IT. Then, cloud comes along. One of the rationales for cloud is that there is an economic impetus.

Of course, not everyone agrees with this. Not everyone agrees with anything about cloud, but if you do cloud correctly, you can cut your utilization waste, reduce your footprint and energy costs, offload peak demands on an elasticity basis, perhaps to third parties, and you can outsource certain apps or data to third parties. Is there an economic benefit from cloud that helps support the investments needed for good SOA?

As we move toward cloud computing, there are more economical and cost-effective architectural options. There is also the ability to play around with SOA in the cloud.



Linthicum: There is, because one of the things people got wrapped around the axle on is having to reinvent their existing systems and go through waves and waves of software and hardware purchases. That became economically nonviable. It was very difficult to figure out how to re-do your architecture, when you had $15-20 million of hardware and software in data center and personnel cost to deal with in support of the new architecture, even though the architecture provides more of a strategic benefit.

As we move toward cloud computing, there are more economical and cost-effective architectural options. There is also the ability to play around with SOA in the cloud, which I think is driving a lot of the SOA. In fact, I find that a lot of people build their first initial SOA as cloud-delivered systems, be it Amazon, IBM, Azure from Microsoft, and some of the other platforms that are out there.

Then, once they figure out the benefits of that, they start putting pieces of it on premise, as it makes sense, and put pieces of it on the cloud. It has the tendency to drive prototyping on the cheap and to leverage architecture and play around with different technologies without the investment we had to do in the past.

It was very difficult to get around that when SOA, as many of the analysts were promoting it, was a big-bang concept and a huge systemic change in how you architecture. Cloud provides a stepwise approach to making that happen. It's much more economic, much more efficient, and it really allows you to play SOA success holistically off of a little success in using the cloud.

Game changing approach

Gardner: Something occurred to me that seems to be a game changing approach or aspect of this. For so long now, people have looked at the total costs of IT, and they went up and up and up. Even though you had things like Moore's Law, commoditization, and maturity that drove some cost down, the total nut of IT for many companies just kept seeming to grow and grow as a percentage of revenue. This, of course, is not a sustainable trajectory.

It seems to me the cloud and SOA as this dream team, as you point out in your book, perhaps provides this inflection point, where we can start to decrease the total nut of IT, rather than just certain aspects of IT. Does that make sense?

Linthicum: It makes perfect sense, and I promote that in the book. One of the things I talk about in Chapter 1 is how things got so bad. The fact of the matter is that we have very ineffective states within the IT realm.

People look at IT and at the movement that's occurred over last 20 years in the progression of the technology, but the reality is that we've gotten a lot less effective in providing benefit to the bottom line of the companies, the missions of the government organizations, and those sorts of things. We need to do better at that.

We've got to stop the insanity. We've got control IT spending.



Ultimately, it's about reinventing the way in which we do IT. In other words, quit thinking about buying the latest and greatest solution and dragging it into the enterprise and having another 20 racks of servers in the data center to support those things that almost never go away. You're getting to a much more complex inflexible state that's not able to change itself or adapt itself to changes in missions or changes in the business. That's just not sustainable in the long-term.

In fact, one of the things I urge IT people to do is to go to a CIO or a COO conference and start talking to them about their IT infrastructure, especially at the cocktail hour. You'll find that it's not a very popular group within most companies and it seems to be, in many instances, the single most limiting factor for them procuring for the companies and growing the business, because of the latency that's in IT.

We've got to stop the insanity. We've got control IT spending. We've got to be much more effective and efficient with the way in which we spend and leverage IT resources. Cloud computing is only a mechanism, it's not a savior for doing that. We need to start marching in new directions and being aggressively innovative around the efficiency, the expandability, and ultimately the agility of IT.

Where the cloud fits

Gardner: Now, looking over your book, Dave, I was impressed by the logic, the layout, and the order of things. You've got a certain level of background and premier information in couple of these chapters on SOA that perhaps we could have been just as well reading in 2005, but the way it fits together is quite interesting. On page 33, you get into when the cloud fits.

That's very much the topic of the day. I speak to a lot of people. Everyone has grokked this general notion of cloud. They understand the private, the public, and "everything as a service," but everybody says, "Yeah, but no one is doing it yet."

What is the right timing for this, and what is the right timing in terms of SOA activities and cloud activities, so they go hand in hand? Are they linear and consecutive? What's the relationship?

Linthicum: They are systemic, one to another. When you're doing SOA and considering SOA within your enterprise or agency, you should always consider cloud as an architectural option. In other words, we have servers we're looking to deploy in middleware, we're looking to leverage in databases we're looking to leverage in terms of SOA. It's governance systems, security systems, and identity management.

Cloud computing is really another set of things that you need to consider in the context of SOA, and you need to start playing around with the stuff now, because it's so cheap. There's no reason that anybody who's working on an SOA shouldn't be playing around with cloud, given the amount of investment that's needed. It's almost nothing, especially with some of the initial forays, some of the prototypes, and some of the pilot projects that need to be done around cloud.

Understanding how cloud computing fits in as a strategic option or another tool in the tool shed, they're able to leverage to drive their architectures.



One really is a matter of doing another. I found out that for people who were deploying SOA their initial success has the tendency to be at least a pure SOA play, as the tendency to be cloud-based. We're doing lots of things in pilot projects that are cloud-oriented and then figuring out how to do that at the enterprise level. Understanding how cloud computing fits in as a strategic option or another tool in the tool shed, they're able to leverage to drive their architectures.

Cloud computing is a fit in many instances. In some instances it's not, and it's a matter of you trying to figure out what's the limitations and the opportunities are within the cloud, before you can figure out what's right to outsource within your own organization.

Gardner: Getting back to where SOA fits in, in Chapter 3, you have a litany of things as a service -- storage, database, information, process, application, platforms, integrations, security, management, governance, testing, and infrastructure. Is there an order? Is there a proper progression? Is there a rationale as to how you should go about all these as services?

The macro domain

Linthicum: You should concentrate on the big macro domain. So, one would be software as a service (SaaS), because SaaS is probably the easiest way to get into the cloud. It also has the most potential to save you the greatest amount of money. Instead of buying a million-dollar, or a two-million-dollar customer reliationship management (CRM) system, you can leverage Salesforce.com for $50-60 a month.

After that, I would progress into infrastructures as a service (IaaS), and that's basically data center on demand. So, it's databases, application servers, WebSphere, and all those sorts of things that you are able to leverage from the data center, but, instead of a data center, you leverage it from the cloud.

Guys like Amazon obviously are in that game. Microsoft, or the Azure platform, are in that game. Any number of players out there are going to be able to provide you with core infrastructure or primitive infrastructure. In other words, it's just available to you over the 'Net with some of kind of a metering system. I would start playing around with that technology after you get through with SaaS.

. . . Instead of having to buy infrastructure and buy a server and set it up and use it, we could go get Google App Engine accounts or Azure accounts.



Then, I would take a look at the platform-as-a-service (PaaS) technology, if you are doing any kind of application development. That's very cool stuff. Those are guys like Force, Google App Engine, and Bungee Labs. They provide you with a complete application development and deployment platform as a service. Then, I would progress into the more detailed stuff -- database, storage, and some of the other more sophisticated services on top of the primitive services that we just mentioned.

Gardner: For those enterprises that do have a sizeable app, Dave, organizations doing a lot of custom development, is that a good place to go for these tests, pilot, and experimental activities? I am going to hazard a guess that this might be the wellspring where cloud has already gotten some attraction, whether organizations recognize it or not?

Linthicum: PaaS with that Google App Engine is driving a lot of innovation right now. People are building applications out there, because they don't have to bother existing IT to get servers and databases brought online, and that will spur innovation.

So, today, we could figure out we want to go off and build this great application and do this great thing to automate a business and, instead of having to buy infrastructure and buy a server and set it up and use it, we could go get Google App Engine accounts or Azure accounts.

Huge potential

Then, we can start building, deploying, defining the database, do the testing, get it up and running, and have it immediately. It's web based and accessible to millions of users who are able to leverage the application in a scalable way. It's an amazing kind of infrastructure when you think about it. The potential is there to build huge, innovative things with very few resources.

Gardner: I'm thinking about the SOA progression over the past five or seven years. One of the cultural organizational obstacles has been getting the development people, the production people, the operation, and the administrator folks to get in some of sort of ongoing feedback loop relationship.

Does cloud PaaS perhaps give a stepping stone approach to start to do that, to think about the totality of an application, the cradle-to-grave iteration, such as the SaaS model, where you've got the opportunity to have a single instance of one code base that you can then work on, rather than have to think about your upgrade cycle.

Linthicum: Yeah, because it's immediately there. That's one thing. There is the instantaneous feedback directly from the users. We can monitor the use. We can monitor the behavior and how people were leveraging the system. We can adjust the system accordingly. The great thing with the SaaS and PaaS models is that we're not doing waves and waves of upgrades that have to be downloaded and then installed, and, in some case, broken.

Now, startups can basically operate with a minimal amount of resources, typically a laptop, pointing at any number of cloud resources.



Everybody is using a centralized platform that's tested as a centralized platform, leveraging the multi-tenant application. We don't have to localize it for Linux, for Windows NT, and for Apple. We just use the platform as web-based, which is perfectly viable these days, when you consider the rich Internet applications (RIAs) out there and the dynamic nature of the interface.

If you're building a SOA and you are building an application instance within the SOA, the opportunities are there to create something that's viable for a long period of time. That's going to be so sustaining, much easier to monitor, and much easier to manage, but the core advantage is, number one, it's much more expandable and also much more cost effective.

We're not having to keep staffs of people around to maintain server hardware and software. We're able to leverage that out in the cloud with a minimal amount of resource consumption. We're also leveling the playing field between small businesses and large businesses.

Ten years ago, it was very difficult to do a start up. You'd have a million dollars in investment funds just to get your infrastructure up and running. Now, startups can basically operate with a minimal amount of resources, typically a laptop, pointing at any number of cloud resources.

A great time

They can build their applications out there. They can build their intellectual capital. They can build their software. They can deploy it. They can test it. Then, they can provision the customers out there and meter their customers. So, it's a great time to be in this business.

Gardner: It cuts across and affects so many aspects, as you say -- the metering, the control of provisions that are more agile, rather than as long upgrades cycles that we traditionally get from commercial software vendors.

I sort of munged two questions together there last time, I want to get back to that culture and organizational issue. This has been something that's a challenge with SOA, and it's going to be a challenge with cloud as well.

Are there organizational stepping-stones or initial preparations that you can do? I'm thinking about IT shared services, perhaps some embracing some vital tenets in ways that you can, in a sense, recast your organization to be in a better position to exploit SOA and then therefore cloud.

There needs to be a lot of education about the opportunities and the advantages of using cloud computing, as well as what the limitations are and what things we have to watch out for.



Linthicum: I think the cultural changes are starting now as far as what cloud computing is going to bring. It's kind of polarizing.

There are two types of people that I run into. Number one: the cloud can do everything and, we really want to move into the cloud -- which is scary. Then there are the people who are looking at the cloud as evil. They always put in front of me all the Gmail adages as proof that the cloud is evil and it's going to destroy their business -- which is also scary.

There needs to be a lot of education about the opportunities and the advantages of using cloud computing, as well as what the limitations are and what things we have to watch out for. Not all applications and all pieces of data are going to be right for the cloud. However, we need to educate people in terms of what the opportunities are.

The fact of the matter is that it's not going to be a dysfunctional and risky thing to move pieces of our architecture out into cloud computing. Get them around the pilot. Get them to go out there and try it. Get them to basically experiment with the technology. Figure out what the capabilities are, and that will ultimately change the culture.

You need to go back to the early '90s. I remember when the Web first came around. I was working for a large corporation, and we weren't allowed to use the Web. If we had to use it, we had to go to the AOL terminal in the library and use it that way.

An understandable asset

Of course, the Web just became bigger, bigger, and bigger and more of an understandable IT asset that could be used enterprise wide. We got web browsers and we're leveraging the Web. The same with the cloud computing. It's going to take a cultural reach. Many large corporations who have embraced the fact are going to put processes and data out on platforms, where they don't know their host.

Gardner: Dave, in Chapter 5, you gave a lot of attention to data. I know there are some people working on that. Tell me about this special relationship between data and SOA, how they come together, and then where cloud fits in?

Linthicum: Understanding data is really the genesis of SOA. A lot of people like to work from the services to the data. I think that the data should be defined and understood in terms of what it is as an as-is state and what it needs to be as a to-be state, where you can build any kind of SOA, using the cloud or not.

Typically, if you're going to leverage the cloud as an infrastructure, it's going to be as a data repository, as well as and for the expandability and the shareability aspects of it, and those sorts of things. However, before you do that, you need to break the data down into a primitive state, understanding what the assets are, what the metadata is, what governance system is around using it -- and just do the traditional architectural stuff.

. . . The data should be defined and understood in terms of what it is as an as-is state and what it needs to be as a to-be state, where you can build any kind of SOA, using the cloud or not.



What I define in the book is definitely cloud related with lots of different examples and different leverages in the context of SOA. But, it's about understanding information the way we've been doing over the last 20 years and then coming up with models and physicals and logicals, trying to figure out what should be where and when we should do that.

It's fairly obvious what pieces and components of the information model you can host in the cloud and which ones need to be on-premise. By the way, it's perfectly acceptable from a performance standpoint to put pieces of physical databases out in the cloud and physical databases on-premise and then leverage those databases simultaneously within the context of applications. You're not going to find tremendous performance differences, and the reliability should be relatively the same.

It's a matter of looking at your information as really a foundation of your architecture, building up on top of that to your services, building up on top of that to your processes, and then really understanding how data exists in the holistic notion of your architecture, in this case, your architecture leveraging cloud computing.

What makes sense

Gardner: Dave, this whole notion of being able to slice and dice data, put it in different places, based on what makes sense for the data, the process, and the applications, rather than simply as a function of the database's needs or the central and core data set needs, strikes a very interesting cord. It allows us to do a lot more interesting things.

In fact, Zimory, another startup, has come out with some interesting announcements, about slicing and dicing caches and then placing them in a variety of ways in different places that can augment and support applications and processes. Are we really going to get to the point soon where we can do things we just never could do before?

Linthicum: We're going to get to a point where the data is going to be a ubiquitous thing. It doesn't really matter where it resides and where we can access it, as long as we access it from a particular model. It's not going to make any difference to the users either. I just blogged about that in InfoWorld.

In fact, we're getting into this notion of what I call the "invisible cloud." In other words, we're not doing application as a service or SaaS, where people get new interfaces that are web-driven. We're putting pieces of the back-end architectural components -- processes, services, and, in this case, data -- out on the platform of the cloud. It really doesn't matter to them where that data resides, as long as they can get at it when they need it.

I don't see a point where we're going to get hindered by where the data resides.



The other aspect of it is because information on a cloud is typically easier to share with other organizations, this has the ability to make the data more valuable by sharing it. That core component becomes a key driver for leveraging the cloud. I don't see a point where we're going to get hindered by where the data resides. We always have to consider governance and security issues and all these things. Every piece of information isn't right for the cloud.

But, for most of the transactional data out there that has semi-private information, which is low-risk -- and that's most of the data from most of the enterprises -- placing pieces of it in the cloud makes sense to better support your architecture and your business. It's perfectly viable.

I don't think people using these information systems are going to have any clue where the information actually resides. IT folks are going to have a tremendous amount of power and numerous options to place in the cloud information that is going to make it much more cost-effective, much more shareable, and therefore much more valuable.

Gardner: Perhaps the takeaway here is that the liberation of data will enliven people in some ways in cloud computing innovation. That really is about business process innovation management. Perhaps that's where we should look to next, and coincidently, that's what your Chapter 7 looks at. Where does business process management fit into cloud, and can that give us something we couldn't do before?

Shared processes

Linthicum: Yeah, it does. We've had the notion of shared processes. In fact, there is a company called Extricity. Back in the old EAI days, it came up with this notion of private versus public processes. Cloud computing provides us with a platform to finally do that. So, not only we are able to drive processes within the enterprise, those going to exist either on premise or in the cloud, depending on where it's best economically and where it's a right architectural fit for those things.

The more important strategic benefit of doing that is that ultimately we're able to put processes on centralized cloud-delivered systems that are shared across multiple enterprises, or multiple divisions in the same enterprise.

This provides us to place an information sharing mechanisms and also process sharing mechanisms, which drives together all of this information in the context of a business process. It allows us to do things like real-time supply-chain automation, real-time event-driven sales-force direction management, and a lot of real-time processes around any business event that spans multiple enterprises. We've been trying to do this for years.

Back in the day, business to business (B2B) was the big buzzword. We had technology guys like Extricity and other process-management technologies to provide us with the capabilities to make this happen. But, it really hasn't been widespread. That's because there was no agreed-on platform to leverage processes and create processes that are shared across multiple enterprises.

All of these things are automated between these very disparate organizations to support the customer better. That's how you're going win this game.



Cloud computing provides us with that capability. So, we have innovators like Appian On Demand and a few other folks out, who are building processes that are sharable on the cloud. We're able to link those to our existing services and data and have our existing systems and our IT assets, such as data and services, participate in these larger process that may span multiple enterprises.

It gets to this point where I can walk into a car dealer and they can tell me exactly when the car I'm ordering is going to show up -- not "8-12 weeks." They know who's going to build it, where the supply is going to come from, where's it going to put together, and how it's going to shipped. All of these things are automated between these very disparate organizations to support the customer better. That's how you're going win this game. That's really the true value of cloud.

Gardner: I agree. We're getting toward extreme visibility all across the exchange -- buyers, sellers, participants, suppliers, and value-added participants. That visibility, of course, gets to more intelligent decision making, less waste, and much higher productivity. Productivity is the key here. If you're in an economy, like we are now, where we've got to grow our way out of this thing, you can't do it by cutting costs forever. The up side is going to come from productivity.

This whole discussion about business process is the cloud discussion that we should be taking to the board of director level, to the COO, and the CFO. They probably don't care too much about the cloud, but they will probably like the fact that the cost for IT can go down. Please help me if you agree or feel free to flesh this out, isn't this the thing that's going to get the business people jazzed?

Bottom-line questions

Linthicum: That's great thinking, Dana. Ultimately, people don't care about whatever hype-driven technology paradigm is coming down the line. Cloud computing can be inclusive of that. How can you save me a buck? How can you get my business out of the doldrums? Can you do that through innovation, and can that innovation cost me less at the end of the day? Those are the questions being asked.

We're not getting, "How can I spend more to get more?" They're saying, "How can we be more effective and efficient with the organization and what innovative changes can make me more effective and efficient?"

Cloud computing is an example of technology that has a potential of doing that. A lot of CIOs and CEOs that I talk to are going to say, "Cloud-Schmoud. I could care less if you do it with pixie dust or cloud computing. I just want it to happen."

Those in IT need understand that this, ultimately, is the motivation. At the end of the day, they need to put together a plan of attack in how to get them to that more effective and efficient state.

IT shops, in the next five years, are going to look very different than they are today. Typically, they're going to be much smaller. They're going to have a lot less hardware and software around, even though it's never going to be eliminated. They're going to be evaluated on their effectiveness and efficiency toward the bottom line in the business.

So, we need to buckle down, be more innovative, figure out what our options are, and figure out a way to move our existing infrastructure in more productive directions.



In the past, we've been exempt from that -- for what reason I don't know -- but they've given IT carte blanche to spend a lot of money. The results come in, but they're not measured as carefully as those in sales and marketing. I think those days are over.

So, we need to buckle down, be more innovative, figure out what our options are, and figure out a way to move our existing infrastructure in more productive directions. Or else, your competitor is going to figure it out before you and they're going to put you out of business.

Gardner: There is a ton of information in this book, but it's still tight and concise. It doesn't go on and on and on. So, I commend you for that. We've got whole chapter on governance. We've got whole chapter on testing. But, the one that really jumped out at me was Chapter 10, "Defining the Candidate Data, Services and Processes for the Cloud."

To me, this really gets at the heart of the issue that IT folks are going to be grappling with. How to get started? What's the right approach for me as an organization for our culture, skills, capabilities, and budgets? How do you tailor this? How do you get started? Maybe you can just dig in and give us a little preview on Chapter 10.

Following the checklist

Linthicum: Chapter 10 is really about what you need to do, once we've gone through these steps of understanding your data, services, and processes, creating a governance model, and understanding security issues and all those things that are good candidates to move onto the cloud?

Once you have this understanding of how to select services, processes, and pieces of data that should be moved out there, it's a matter of going through those checklists to see if the processes, applications, and data are independent or loosely coupled.

If they're independent, then the chances are they're going to more easy to move out to the cloud. If they're loosely coupled, they're easy to move out to the cloud. If they're interdependent, which means they're bound to different things, it's very difficult to decouple them and move them out to the cloud.

You need to figure out the points of integration. Ultimately, if we move something out to the cloud, can we link that information back to the enterprise, can we do that in efficient and effective way, and will that lower costs for us?

You are not going to be able to put cloud computing on top of an existing dysfunctional architecture and expect miracles to occur.



In many instances, we can put systems out in the cloud and we can say it's more cost-effective to have them out there? But when you factor in the integration cost, it's much less cost-effective and much less effective and efficient for the enterprise. You find that with the lot of the salesforce.com installations. Integration wasn't really factored in, and it ended up being a huge issue.

You need to consider your security. You need to consider the core internal enterprise architecture and making sure that it's healthy. You are not going to be able to put cloud computing on top of an existing dysfunctional architecture and expect miracles to occur. As part of this process, as you mentioned earlier Dana, you need to understand that cloud computing needs to be leveraging the context of the SOA, which spans on-premise and off-premise.

This is about getting your existing architecture healthy and leveraging cloud computing as an option. It's not really bolting cloud computing onto existing bad architecture and hoping for changes that are never going to occur.

Looking at the cost models

Ultimately, it's about looking at the cost models and trying to figure out which are the right candidates to move out the cloud in terms of the efficiencies and effectiveness, while looking at the strategy of the company.

I was helping a disaster company a while back. It had to go from 10 users to 10,000 users in a week. Cloud computing is a great candidate for those things and those types of processes. Instead of having a data center that's dark and that you turn on and fire up whenever you need the capacity, you can just go ahead and call Amazon or Google and turn on the capacity to make that happen.

Those are good candidates for cloud computing. But, you need to consider governance, security, how tightly or loosely coupled those processes are within the system, cost effectiveness, integration, other assets of data, the larger strategy of the company, and the direction of the IT architecture and where it's looking to go.

All those things are fundamental considerations of whether or not something that you've identified as a core component and understood as a core component are outsourced to the cloud or not.

Instead of having a data center that's dark and that you turn on and fire up whenever you need the capacity, you can just go ahead and call Amazon or Google and turn on the capacity to make that happen.



Gardner: Then, you come into Chapter 11. It's a practical and pragmatic tip on analyzing and providing candidates around platforms and around picking private or public approaches. One of the things that occurred to me in looking that over is that perhaps now is the time for companies to be thinking along these lines as well. That's how to protect themselves against lock-in and making choices they might regret later. This is around the whole neutrality and portability issue.

While we're experimenting, Dave, and while we're getting our feet wet with cloud, this is also a good time to start putting pressure on all the parties involved for as much neutrality in standards and portability as possible.

Linthicum: It is, and that's not there, generally speaking, in the cloud community. We have security that's still lacking a bit. We have to figure out better mechanisms for that, and for portability, which is still lacking. We have to figure out better mechanisms for that.

So, you have to factor that into the cost and the risk. Right now, if you're moving into the cloud, and you're going to localize a system for a cloud provider, it's going to be very difficult in the future to take that code and data off of that system and put it on another cloud provider, or, in some instances, bring it on premise.

Looking at standards

As you look at the cloud providers, one of the factors in selecting those guys is number one, do they have a vision for interoperability standards? When will that vision be laid out? What kind of standards organizations are they bound to currently, and how are those standards organizations progressing? What does your application do that's going to cause portability issues?

If they're trying to sell you their cloud, have them look at your application and tell you how easy is it for that application, either new or porting to the system, to move off that system in time in the future.

Typically, the pat answer is that it's easy to port your system off because they're using some standard language and a standard database. But, you'll find that many proprietary application programming interfaces (APIs) and interfaces are there, and they're going to make portability very difficult. All the different cloud providers have built their infrastructure and their products in their own little proprietary ways, because they haven't done close coordination one to another.

It's up to the customers to throw their weight around. You have to build it with your dollars.



So that's going to be a trade-off going forward, and I would grill your cloud computing provider of choice to make sure that they have some kind of a vision going forward and how they are going to provide interoperability. But I think it's going to be some time before it occurs, I am a lot more skeptical than some of the other people out there, and it's going to take a lot of customers who are actually paying these guys money to demand that portability exists and they adhere to some sort of standards.

Gardner: It's up to the market to throw its weight around, right?

Linthicum: It's up to the customers to throw their weight around. You have to build it with your dollars.

Gardner: I also suppose that lessons learned in the software realm over the past 10 or 20 years -- having good contracts, having lawyers look things over, writing the proper safeguards in, whether it's indemnification or what have you -- should all be brought right along into the cloud domain. All those lessons learned in software should not in any way be forgotten?

Understanding the contract

Linthicum: That's right. We had a recent issue. It was well-publicized problem with an on-demand CRM provider and Pulte Homes, and they had a problem with the contracts. They didn't understand the contracts and things went wrong in their implementation. The CRM provider, the SaaS provider, wouldn't let them out of their agreement and made them pay fees for basically no services provided.

I'd argue that there are some customer service issues there on the SaaS provider area, but the customer ultimately needed to read the contracts to make sure they understand what the issues are and any kind of consequences that will come out of that. At the end of the day, we're getting into contractual agreements again. You have to approach them with your eyes open and understanding how the stuff is going to work.

Gardner: Now, closing up a little bit, we've certainly seen a lot of projections from folks like Forrester, Gartner and IDC. There are a lot of different numbers and lots of throwing darts at the various boards around these organizations. But, all of them seem to be quite bullish on cloud and that this is something that's here to stay and is going to be high growth.

I think cloud computing is going to grow a lot over time and just become part of the infrastructure.



When I speak to a lot of folks like you, they are very busy. There is lot of demand for data-center transformation, modernization, and virtualization. These are under-girding movements that will enable or support cloud options. So, how about some forecast Dave? Even if it's in general terms, this is really quite a growth opportunity.

Linthicum: It is. It is. The funny thing in cloud is that it's this big amorphous thing and it's tough to name. In fact, I was kind of wrestling around when using cloud computing as the title of the book, because we're getting into something that's been around for a long period of time as an existing concept. But, I think cloud computing is going to grow a lot over time and just become part of the infrastructure.

We've been using aspects of cloud computing for years and years. Application service providers (ASPs) and SaaS were the first forays into cloud. Now, were using additional infrastructure providers, such as database and middleware and applications, and all those things that we're able to deliver as infrastructure and as service. Then, we're also getting development platforms that come out of the cloud and office automation systems like Google Docs, and Office Live.

Things are going to move from our clients and from our data centers out into the cloud providers through economics of scale and efficiency. When it comes right down to it, there are very innovative solutions out there, and coolness is going to drive people to the cloud.

Economies of scale

In other words, you're going to be able to turn off very inefficient and cost-inefficient applications and turn on these that are cloud delivered. Through the sharing mechanism, the RO update mechanisms, economies of scale, the scalability of it, and the amount of money you're going to have to spend on the cloud versus on-premise system, it's just going to be the way to go.

In the next 10 years, IT, as I mentioned earlier, is going to be very different place. I'm not one of those guys that thinks everything in the existing IT infrastructure is going to exist on some cloud some place. But, a good majority of our applications and our processes, things that exists on premise these days, are going to exist in the cloud. It's just going to be the way in which we do IT.

I look forward to working in that environment. I think it's going to be a lot of fun.



It's not going to be that different than leveraging the Web presence that we're doing these days. Cloud computing is about putting additional IT assets out on the platform of the Web. The adoption curve is going to be very much like the Web adoption curve was in the '90s. Significant cost savings are going to be made. We're going to be a much better, more effective place, and it's much more exciting as an IT person. I look forward to working in that environment. I think it's going to be a lot of fun.

Gardner: I agree. It's going to be very exciting. Well thanks. We have been talking with Dave Linthicum. He has come out with a new book, Cloud Computing and SOA Convergence in Your Enterprise: A Step-by-Step Guide. It's coming to the market through Addison-Wesley Information Technology Series publishers.

It's out now on all the usual book purchasing sites and, as you pointed out, it's also on Kindle. That's very exciting. I want to thank you, Dave. It's been really enjoyable and a great way for us to get into a lot of the interesting aspects of cloud and SOA. So I wish you well on your book.

Linthicum: Thank, you Dana.

Gardner: I also want to thank our sponsors for the BriefingsDirect Analyst Insights Edition podcast series. They are Active Endpoints and TIBCO Software.

Thanks again for listening. This is Dana Gardner, principal analyst at Interarbor Solutions. You've been listening to a BriefingsDirect podcast. Thanks, and come back next time.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download a transcript. Charter Sponsor: Active Endpoints. Also sponsored by TIBCO Software.

Special offer: Download a free, supported 30-day trial of Active Endpoint's ActiveVOS at www.activevos.com/insight.

Take the BriefingsDirect middleware/ESB survey now.

Edited transcript of BriefingsDirect Analyst Insights Edition podcast, Vol. 45 with consultant Dave Linthicum on the convergence of cloud computing and SOA. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.

Sunday, October 25, 2009

Application Transformation Case Study Targets Enterprise Bottom Line with Eye-Popping ROI

Transcript of the first in a series of sponsored BriefingsDirect podcasts -- "Application Transformation: Getting to the Bottom Line" -- on the rationale and strategies for application transformation.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Learn more. Sponsor: Hewlett-Packard.


Gain more insights into "Application Transformation: Getting to the Bottom Line" via a series of HP virtual conferences Nov. 3-5. For more on Application Transformation, and to get real time answers to your questions, register to the virtual conferences for your region:
Register here to attend the Asia Pacific event on Nov. 3.
Register here to attend the EMEA event on Nov. 4.
Register here to attend the Americas event on Nov. 5.


Dana Gardner: Hi, this is Dana Gardner, principal analyst at Interarbor Solutions, and you’re listening to BriefingsDirect.

This podcast is the first in the series of three to examine Application Transformation: Getting to the Bottom Line. We'll discuss the rationale and likely returns of assessing the true role and character of legacy applications, and then assess the true paybacks from modernization.

The ongoing impact of the reset economy is putting more emphasis on lean IT -- of identifying and eliminating waste across the data-center landscape. The top candidates, on several levels, are the silo-architected legacy applications and the aging IT systems that support them.

We'll also uncover a number of proven strategies on how to innovatively architect legacy applications for transformation and for improved technical, economic, and productivity outcomes. The podcasts coincidentally run in support of HP virtual conferences on the same subjects.

Here to start us off on our series on the how and why of transforming legacy enterprise applications are Paul Evans, worldwide marketing lead on Applications Transformation at HP. Welcome Paul.

Paul Evans: Hi, Dana.

Gardner: We're also joined by Luc Vogeleer, CTO for Application Modernization Practice in HP Enterprise Services. Welcome to the show, Luc.

Luc Vogeleer: Hello, Dana. Nice to meet you.

Gardner: Let's start with you, Paul, if you don't mind. You have this virtual conference coming up, and the focus is on a variety of use cases for transformation of legacy applications. I believe this has gone beyond the point in the market where people do this because it's a "nice to have" or a marginal improvement. We've seen it begin with a core of economic benefits here.

Evans: It's very interesting to observe what has happened. When the economic situation hit really hard, we definitely saw customers retreat, and basically say, "We don't know what to do now. Some of us have never been in this position before in a recessionary environment, seeing IT budgets reduce considerably."

That wasn't surprising. We sort of expected it across all of HP. People had prepared for that, and I think that's why the company has weathered the storm. But, at a very macro level, it was obvious that people would retrench and then scratch their heads and say, "Now what do we do?"

A different dynamic

Now, six months or nine months later, depending on when you believe the economic situation started, we're seeing a different dynamic. We're definitely seeing something like a two-fold increase in what you might call "customer interest." The number of opportunities we're seeing as a company has doubled over the last six or nine months.

I think that's based on the fact, as you pointed out, that if you ask any CIO or IT head, "Is application transformation something you want to do," the answer is, "No, not really." It's like tidying your garage at home. You know you should do it, but you don't really want to do it. You know that you benefit, but you still don't want to do it.

Because of the pressure that the economy has brought, this has moved from being something that maybe I should do to something that I have to do, because there are two real forces here. One is the force that says, "If I don't continue to innovate and differentiate, I go out of business, because my competitors are doing that." If I believe the economy doesn't allow me to stand still, then I've got it wrong. So, I have to continue to move forward.

Secondly, I have to reduce the amount of money I spend on my innovation, but at the same time I need a bigger payback. I've got to reduce the cost of IT. Now, with 80 percent of my budget being dedicated to maintenance, that doesn't move my business forward. So, the strategic goal is, I want to flip the ratio.

I want to spend more on innovation and less on maintenance. People now are taking a hard look at, "Where do I spend my money? Where are the proprietary systems that I've had around for 10, 20, 30 years? Where do these soak up money that, honestly, I don't have today anymore?"

One of the biggest challenges we face is that customers obviously believe that there is potential risk. Of course there is risk, and if people ask us, we'll tell them.



I've got to find a cheaper way, and I've got to find solutions that have a rapid return on investment (ROI), so that maybe I can afford them, but I can only afford them on the basis that they are going to repay me quickly. That's the dynamic that we're seeing on a worldwide basis.

That's why we've put together a series of webinars, virtual events that people can come to and listen to customers who've done it. One of the biggest challenges we face is that customers obviously believe that there is potential risk. Of course there is risk, and if people ask us, we'll tell them.

Our job is to minimize that risk by exposing them to customers who have done it before. They can view those best-case scenarios and understand what to do and what not to do. Remember, we do a lot of these things. We've built up massive skills experience in this space. We're going to share that on this global event, so that people get to hear real customers talking about real problems and the benefits that they've achieved from that.

We'll top-and-tail that with a session from Geoffrey Moore, who'll talk about where you really want to focus your investment in terms of core and context applications. We'll also hear from Dale Vecchio, vice president research of Gartner, giving us some really good insight as to best practices to move forward. That's really what the event is all about -- "It's not what I want to do, but it's what I am going to have to do."

Gardner: I've seen the analyst firms really rally around this. For example, this week I've been observing the Forrester conference via Twitter, reading the tweets of the various analysts and others at the conference. This whole notion of Lean IT is a deep and recurring topic throughout.

It seems to me that we've had this shift in psychology. You termed it a shift from "want to" to "must." I think what we've seen is people recognizing that they have to cut their costs and bite the bullet. It's no longer putting this off and putting this off and putting this off.

Still don't understand

Evans: No. Part of HP's portfolio is hardware. For a number of years, we've seen people who have consulted with us, bought our equipment to consolidate their systems and virtualize their systems, and built some very, very smart Lean IT solutions. But, when they stand back from it, they still say, "But, the line-of-business manager still giving me the heartache that it takes us six months to make a change."

We're still challenged by the fact that we don't really understand the structure of our applications. We're still challenged by the fact that the people who know about these applications are heading toward retirement. And, we're still challenged by the thought of what we're going to do when they're not here. None of that has changed.

Although every day we're finding inherently smarter ways to use silicon, faster systems, blade systems, and scaling out, the fundamental thing that has affected IT for so many years now is right, smack dab in the cross hairs of the target -- people saying that this is done properly, we'll improve our agility, our differentiation, and innovation, at the same time, cutting costs.

In a second, we'll hear about a case study that we are going to talk about at these events. This customer got an ROI in 18 months. In 18 months, the savings they had made -- and this runs into millions of dollars -- had been paid for. Their new system, in under 18 months, paid for itself. After that, it was pure money to the bottom-line, and that's what this series is all about.

Gardner: Luc, we certainly have seen both from the analysts as well as from folks like HP, a doubling or certainly a very substantial increase in inquires and interest in doing legacy transformation. The desire is there. Now, how do we go beyond theory and get into concrete practice?

Vogeleer: From an HP perspective, we take a very holistic approach and look at the entire portfolio of applications from a customer. Then, from that application portfolio -- depending on the usage of the application, the business criticality of the application, as well as the frequency of changes that this application requires -- we deploy different strategies for each application.

We not only focus on one approach of completely re-writing or re-platforming the application or replacing the application with a package, but we go for a combination of all those elements. By doing a complete portfolio assessment, as a first step into the customer legacy application landscape, we're able to bring out a complete road map to conduct this transformation.

This is in terms of the sequence in which the application will be transformed across one of the strategies that we will describe or also in terms of the sequence in time. We first execute applications that bring a quick ROI. We first execute quick wins and the ROI and the benefits from those quick wins are immediately reinvested for continuing the transformation. So, transformation is not just one project. It's not just one shot. It's a continuous program over time, where all the legacy applications are progressively migrated into a more agile and cost-effective platform.

Gardner: It certainly helps to understand the detail and approach to this through an actual implementation and a process. I wonder if you could tell us about the use case we're going to discuss, some background on that organization, and their story?

Vogeleer: The Italian Ministry of Instruction, University and Research (MIUR), is the customer we're going to cover with this case, is a large governmental organization and their overall budget is €55 billion.

This Italian public education sector serves 8 million students from 40,000 schools, and the schools are located across the country in more than 10,000 locations, with each of those locations connected to the information system provided by the ministry.

Very large employer

The ministry is, in fact, one of the largest employers in the world, with over one million employees. Its system manages both permanent and temporary employees, like teachers and substitutes, and the administrative employees. It also supports the ministry users, about 7,000 or 8,000 school employees. It's a very large employer with a large number of users connected across the country.

Why do they need to modernize their environment? In fact, their system was written in the early 1980s on IBM mainframe architecture. In early 2000, there was a substantial change in Italian legislation, which was called so-called a Devolution Law. The Devolution Law was about more decentralization of their process to school level and also to move the administration processes from the central ministry level into the regions, and there are 20 different regions in Italy.

This change implied a completely different process workflow within their information systems. To fulfill the changes, the legacy approach was very time-consuming and inappropriate. A number of strong application have been developed incrementally to fulfill those new organizational requirements, but very quickly this became completely unmanageable and inflexible. The aging legacy systems were expected to be changed quickly.

In addition to the element of agility to change application to meet the new legislation requirement, the cost in that context went completely out of control. So, the simple, most important objective of the modernization was to design and implement a new architecture that could reduce cost and provide a more flexible and agile infrastructure.

Gardner: We certainly get a better sense of the scope with this organization, a great deal of complexity, no doubt. How did you begin to get into such a large organization with so many different applications?

So, the simple, most important objective of the modernization was to design and implement a new architecture that could reduce cost and provide a more flexible and agile infrastructure.



Vogeleer: The first step we took was to develop a modernization road map that took into account the organizational change requirements, using our service offering, which is the application portfolio assessment.

From the standard engagement that we can offer to a customer, we did an analysis of the complete set of applications and associated data assets from multiple perspectives. We looked at it from a financial perspective, a business perspective, functionality and the technical perspective.

From those different dimensions, we could make the right decision on each application. The application portfolio assessment ensured that the client's business context and strategic drivers were understood, before commencing a modernization strategy for a given application in the portfolio.

A business case was developed for modernizing each application, an approach that was personalized for each group of applications and was appropriate to the current situation.

Gardner: How many people were devoted to this particular project?

Some 19,000 programs

Vogeleer: In the assessment phase, we did it with a staff of seven people. The seven people looked into the customer's 20 million lines of code using automated tools. There were about 19,000 programs involved into the analysis that we did. Out of that, we grouped the applications by their categories and then defined different strategies for each category of programs.

Gardner: How about the timing on this? I know it's a big complicated and can go on and on, but the general scoping, the assessment phase, how long do these sorts of activities, generally take?

Vogeleer: If we look at the way we conducted the program, this assessment phase took about three months with the seven people. From there, we did a first transformation pilot, with a small staff of people in three months.

After the pilot, we went into the complete transform and user-acceptance test, and after an additional year, 90 percent of the transformation was completed. In the transformation, we had about 3,500 batch processes. We had the transformation. We had re-architecting of 7,500 programs. And, all the screens were also transformed. But, that was a larger effort with a team of about 50 people over one year.

Gardner: Can you tell us about where they ended up? One of the things I understand about transformation is you still needed to asses what you’ve got, but you also need to know where you are going to take it?

We had the transformation. We had re-architecting of 7,500 programs.



Vogeleer: As I indicated at the beginning, we have a mixture of different strategies for modernization. First of all, we looked into the accounting and HR system, and the accounting and HR system for non-teacher employees. This was initially written on the mainframe and was carrying a low level of customization. So, there was a relatively limited need for integration with the rest of the application portfolio.

In that case, we selected Oracle HR Human Resources, Oracle Self-Service Human Resources, and Oracle Financial as the package to implement. The strategy for that component was to replace them with packaged applications. Twenty years ago, those custom accounting packages didn't exist and were completely written in COBOL. Now, with existing suitable applications, we can replace them.

Secondly, we did look into the batch COBOL applications on the mainframe. In that scenario, there were limited changes to those applications. So, a simple re-platforming of the application from the IBM 3070 onto a Linux database was sufficient as an approach.

More important were all the transactional COBOL/CICS applications. Those needed to be refracted and re-architected to the new platform. So, we took the legacy COBOL sources and transformed them into Java.

Also, different techniques were used there. We tried to use automated conversion, especially for non-critical programs, where they're not frequently changed. That represented 60 percent of the code. This code could be then immediately transferred by removing only the barriers in the code that prevented it from compiling.

All barriers removed

We had also frequently updated programs, where all barriers were removed and code was completely cleaned in the conversion. Then, in critical programs, especially, the conversion effort was bigger than the rewrite effort. Thirty percent of the programs were completely rewritten.

Gardner: You said that 60 percent of the code was essentially being supported through these expensive systems, doing what we might consider commodity functionality nowadays.

Vogeleer: Let me clarify what happens with those 60 percent.

We considered that 60 percent of the code was code that was not frequently changed. So, we used automatic conversion of this code from COBOL to Java to create some automatically translated Java procedures. By the way, this is probably not easy to read, but the advantage is that, because it was not often changed, the day that we need to change it, we already have Java source code from which we can start. That was the reason to not rewrite it, but to do automated conversion from COBOL to Java.

Gardner: Now we've certainly got a sense of where you started and where you wanted to end up. What were the results? What were some of the metrics of success -- technical, economic, and in productivity?

End-user productivity, as I mentioned, is doubled in terms of the daily operation of some business processes. Also, the overall application portfolio has been greatly simplified by this approach.



Vogeleer: The result, I believe, was very impressive. The applications are now accessed through a more efficient web-based user interface, which replaces the green screen and provides improved navigation and better overall system performance, including improved user productivity.

End-user productivity, as I mentioned, is doubled in terms of the daily operation of some business processes. Also, the overall application portfolio has been greatly simplified by this approach. The number of function points that we're managing has decreased by 33 percent.

From a financial perspective, there are also very significant results. Hardware and software license and maintenance cost savings were about €400,000 in the first year, €2 million in the second year, and are projected to be €3.4 million this year. This represents a savings of 36 percent of the overall project.

Also, because of the transfer from COBOL to Java technology and the low-cost of the programmers and the use of packaged application, development has now dropped by 38 percent.

Gardner: I think it's very impressive. I want to go quickly to Paul Evans. Is this unusual? Is this typical? How constant are these sorts of returns, when we look at a transformation project?

Evans: Well, of course, as a marketing person I'd say that every time we get this return, and everybody would laugh like you. In general, people are very keen on total cost of ownership (TCO) and ROI, especially the ROI. They say, "Look, maybe I can afford something, but I've got to feel certain that I am going to get my money back -- and quickly."

ROI of 18-24 months

I don't want to say that you're going to get it back in 10 years time. People just aren’t going to be around that long. In general, when we're doing a project, as we did here in Italy, which combines applications modernization and an infrastructure renew, an ROI of around 18-24 months is usually about the norm.

We have tools online. We have a thing called the TCO Challenge. People can insert the configuration of the current system today. Then, we promote a comparable system from HP in terms of power and performance and functionality. We provide not only the price of that system, but, more importantly, we provide the TCO and ROI data. Anyone can go online and try that, and what they'll see is an ROI of around 18 months.

This is why I think we're beginning to see this up-take in momentum. People are hearing about these case studies and are beginning to believe that this is not just smoke and mirrors, and it's not marketing people like me all the time.

People like Luc are out there at the coalface, working with customers who are getting these results. They are not getting the results because there is something special or different. This solution was a type that we deliver every day of the week, and these results are fairly commonplace.

. . . the new programing style is very much integrated with the convergence tool, with the migration tools, and allows the new generation of programmers to work with those migration tools very easily.



Gardner: Luc, certainly the scale of this particular activity, this project set, convinces me that the automation is really key. The scale and the size of the code base that you dealt with, the number of people, and the amount of time that were devoted are pretty impressive. What's coming next down the avenue in terms of the automation toolset? I can only assume that this type of activity is going to become faster, better, and cheaper?

Vogeleer: Yes, indeed. What we realized here is that, although we didn't rewrite all the code, 80 percent of the migrated code that we did by automated tools is very stable and
infrequently modified. We have a base from which we can easily rework.

Tools are improving, and we see also that those tools are growing in the direction of being integrated with integrated development environments (IDEs) that the programs can use. So, it becomes very common that the new programing style is very much integrated with the convergence tool, with the migration tools, and allows the new generation of programmers to work with those migration tools very easily.

Gardner: And, the labor pools around the world that produce the skill sets that are required for this are ready and growing. Is that correct?

Vogeleer: Yes, that's right. As I indicated, the savings that were achieved in terms of development cost by changing the programing language, because of the large pool of programmers that we can have and the lower labor cost, dropped the development cost by 38 percent.

Gardner: Very good. We've certainly learned a lot about the paybacks from transformation of legacy enterprise applications and systems. This podcast is the first in a series of three to examine application transformation getting to the bottom-line.

There is also a set of webinars and virtual conferences from HP on the same subject. I want to thank our guests for today’s insights and the use-case of the Italian Ministry of Instruction, University and Research (MIUR). Thanks, Paul Evans, worldwide marketing lead on Applications Transformation at HP.

Evans: Thanks, Dana.

Gardner: We’ve also been joined by Luc Vogeleer, CTO for the Application Modernization Practice in HP Enterprise Services. Thanks so much, Luc.

Vogeleer: Thank you, Dana.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You’ve been listening to a sponsored BriefingsDirect podcast. Thanks for listening, and come back next time.



Gain more insights into "Application Transformation: Getting to the Bottom Line" via a series of HP virtual conferences Nov. 3-5. For more on Application Transformation, and to get real time answers to your questions, register to the virtual conferences for your region:
Register here to attend the Asia Pacific event on Nov. 3.
Register here to attend the EMEA event on Nov. 4.
Register here to attend the Americas event on Nov. 5.


Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Learn more. Sponsor: Hewlett-Packard.

Transcript of the first in a series of sponsored BriefingsDirect podcasts -- "Application Transformation: Getting to the Bottom Line" -- on the rationale and strategies for application transformation. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.

Thursday, October 15, 2009

Making the Leap from Virtualization to Cloud Computing: A Roadmap and Guide

Transcript of a sponsored BriefingsDirect podcast on what enterprise architects need to consider when moving from virtualization to cloud computing.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Learn more. Sponsor: Hewlett-Packard.

Get a free copy of Cloud 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 making a leap from virtualization to cloud computing. We’ll hammer out a typical road map for how to move from virtualization-enabled server, storage, and network utilization benefits to the larger class of cloud computing agility and efficiency.

How should enterprise IT architects scale virtualized environments so that they can be managed for elasticity payoffs? What should be taking place in virtualized environments now to get them ready for cloud efficiencies and capabilities later? And how do service-oriented architecture (SOA), governance, and adaptive infrastructure approaches relate to this progression or road map from tactical virtualization to powerful and strategic cloud computing outcomes?

Here to help you answer these questions and to explain more about properly making a leap from virtualization to cloud computing, we are joined by two thought leaders from Hewlett-Packard. Please join me in welcoming Rebecca Lawson, director of Worldwide Cloud Marketing at HP. Hi, Rebecca.

Rebecca Lawson: Hi. Good morning.

Gardner: We're also joined by Bob Meyer, the worldwide virtualization lead in HP’s Technology Solutions Group. Welcome back, Bob.

Bob Meyer: Thanks, Dana. Hi, Rebecca.

Gardner: Let’s start by looking at market maturity. With the economy lately, we've certainly seen enough people looking for efficiencies and seeking out ways of extending the infrastructure so they can support more applications, data, network, and services. But, how do we go to the next level? What should you be thinking about now? Let me take that first to you, Rebecca.

Lawson: What we're seeing is that there has been an acceleration of our customers to start to get their infrastructure in order -- to get it virtualized, standardized, and automated -- because they want to make the leap from being a technology provider to a service provider.

Many of our customers who are running an IT shop, whether it’s enterprise or small and mid-size, are starting to realize -- thanks to the cloud -- that they have to be service-centric in their orientation. That means they ultimately have to get to a place, where not only is their infrastructure available as a service, but all of their applications and their offerings are going in that direction as well.

Gardner: Bob, just by virtualizing doesn’t mean you're services-enabling. Does it?

Focus on the service

Meyer: No, it’s a good start. I couldn’t agree more with Rebecca. We're seeing the same thing. A couple of years ago, people were talking about virtualization. The focus was all on the server and hypervisor. The real positive trend is to focus on the service.

How do I take this infrastructure, my servers, my storage, and my network and make sure that the plumbing is right and the connectivity is right between them to be agile enough to support the business? How do I manage this in a holistic manner, so that I don’t have multiple management tools or disconnected pools of data that I can’t drive my IT with.

What’s really positive is that the top-down service perspective that says virtualization is great, but the end point is the service. On top of that virtualization, what do I need to do to take it to the next level? And, for many people now that next level they are looking at is the cloud, because that is the services perspective.

With inward virtualization, as Rebecca said, there are moves to standardize on hypervisors and on different platforms, and, also as we’ve said in the past, virtualization is like the hand, and automation is like the glove. They fit together.

How do you scale virtualization and apply it more cost-effectively and bringing things like compliance? That’s where automation comes in. So, we are seeing all those things together in the notion of how to do this for the service.

Gardner: This strikes me as somewhat of an abstraction or perhaps scaling issue. In virtualization you might have a number of platforms that you would virtualize. You bring more applications across them and increase your utilization.

You talked about "pool," but when we talk about cloud, we're talking about pools of pools, making that something that you could access with more automation and less complexity.

The funny thing is that a lot of people are trying to make a link between virtualization and cloud computing. We think there is a link, but it’s not just a straight-line progression.



In fact, the people who are managing processes might want to access these pools of resources, rather than a traditional IT road map. Does that make sense to you, Rebecca? Are we talking about an abstraction from virtualization, and that cloud is just more of it?

Lawson: That’s a good question. The funny thing is that a lot of people are trying to make a link between virtualization and cloud computing. We think there is a link, but it’s not just a straight-line progression. In cloud computing, everything is delivered as a service, and that’s pretty intuitive to anybody who has used any cloud service like eBay, for example. Social networking is pretty obvious.

What's really useful about cloud services like those is that they're not necessarily used inside the enterprise, but what they are doing is they are causing IT to focus on the end-game. Very specifically, what are those business services that we need to have and that business owners need to use in order to move our company forward?

Do a few things well

For example, if you're a financial services company, you're focused very specifically on doing a few things well, which may be managing financial instruments. Not only are our customers starting to get successful with their virtualization strategy, building from the bottom up, and getting really efficient with pools of infrastructure, but they are starting to think in a more top-down point of view to say, "What is it that we really need to do well? Is it to provide technologies?" The answer is that they need to provide technology-enabled services, and that reorients their thinking a lot.

I want to mention that the scaling that you think of, when you think about cloud services, is not really what most enterprises need to achieve and they won’t achieve it, because they are managing so many different types of workloads. Naturally, every organization has to manage a lot of kinds of workloads. So, the more variation you have the less efficient you will be, but that doesn’t mean you can’t work for its efficiencies.

We're learning lesson from the big cloud service providers on how to standardize, where to standardize, how to automate, how to virtualize, and we're using the lessons that we are seeing from the big-cloud service providers and apply them back into the enterprise IT shop. But, you’ve got to have realistic expectations too. You are not going to get the same economies of scale as an Amazon or Google, if you are just a regular IT shop. Obviously, that’s not going to be the case.

Gardner: At the risk of over-simplifying, Bob, if we look at virtualization as a set of capabilities or a progression to move through, it seems that SOA is also important as a necessary step to be able to scale and get to cloud benefit. Is there a relationship here? Are people starting to embrace SOA, as they start to virtualize, or vice-versa? How does that work?

Meyer: We see them as parallel streams. If you go back a couple of years and get back to the service notion, people had equated virtualization as an infrastructure thing, and SOA as an application thing, and treated them on different tracks. But, when you take them in the notion of how to provide those technology-enabled services that Rebecca talked about, you could start to see how the thoughts merged together.

SOA eventually comes into that conversation, because you work through the service stack, and that’s just another part of the equation.



It’s not only efficiencies in the infrastructure, in the connecting and delivering that together, but you are also applying those same lessons to the application side. They do come together, when you're having a cloud conversation, and that’s the interesting part about it as well.

When people talk to us and ask, “How do I leverage virtualization to get to be an efficient cloud provider,” SOA eventually comes into that conversation, because you work through the service stack, and that’s just another part of the equation.

Gardner: When we look to a payoff, virtualization can often help in terms of return on investment (ROI) and total cost of ownership (TCO) to a certain level, when we're talking about standardization, utilization rates increasing, cutting your energy footprint, labor cost, and so forth.

But, if we can progress to that cloud benefit, where we might be able to actually start using third-party clouds to off-load certain spikes or types and character of workload, that strikes me as a real economic benefit here. Are people who are thinking about virtualization recognizing that they are setting themselves up for a much larger payoff should they make the progression to cloud computing? Let me open that up to either one of you.

Broader implications

Meyer: I’ll just open here and say the cloud discussion is important, because it looks at the way that you consume and deliver services. It really does have broader implications to say that now as a service provider to the business, you have options.

Your option is not just that you buy all the infrastructure components. You plumb them together, monitor them, manage them, make sure they're compliant, and deliver them. It really opens up the conversation to ask, "What’s the most efficient way to deliver the mix of services I have?"

The end result really is that there will be some that you build, manage, and manage the compliance on your own in the traditional way. Some of them might be outsourced to manage service providers. For some, you might source the infrastructure or the applications from the third-party provider.

This cloud conversation really is a conversation about what’s the best mix of service options for me to deliver to the business. And, how do I balance the risk, the cost, and the compliance across all of those? That’s the crux of the conversation. It’s a little bit beyond just a cloud. It becomes about the best and most efficient way for me to provide services to business.

Lawson: In fact, we're using one of the steps between virtualization and going out and sourcing cloud services. That's this notion of converged infrastructure, or as we’ve called it at HP, "adaptive infrastructure."

. . . The industry is starting to appreciate that we are moving from virtualization of just compute to a complete converged infrastructure.



We’ve started to come out with some products that make it incredibly easy to provision and de-provision a complete infrastructure. In other words, that's an in-a-box server storage network, everything ready to go, automation software so that you can spin up a virtualized machine on a logical, virtual, or physical server right from a catalogue that’s embedded into the whole BladeSystem.

So, the industry is starting to appreciate that we are moving from virtualization of just compute to a complete converged infrastructure. That abstracts away so much of the complexity. That means that IT can quickly serve the demand of their constituents who are typically appdev, test, or operations folks who need whatever they need "right now, right now, right now."

It’s actually a pretty exciting time, because we're moving into this converged infrastructure, and virtualization is becoming just part of that fabric. It’s almost embedded in that. It’s assumed that you can use a virtualized environment and that is it not so hard anymore.

That leads you to a place, where you can make, as Bob mentioned, a smart sourcing decision to say -- maybe for certain workloads -- "Do we want to go to a third-party or an outsourced cloud-based infrastructure offering or a cloud-based service that encapsulates infrastructure behind the application?"

Gardner: Perhaps one way to characterize this is that for the investment you make in virtualization, adaptive infrastructure, and SOA, you might get some pretty good payoffs, even in the short-medium term. You are setting yourself up and you are making investments for a much larger return, which is in that flexibility of sourcing and/or finding the right fit at the service level, but with perhaps an underlying fabric on the providing level. Does that make sense?

Lawson: It does. That’s exactly right.

Part of the picture

Meyer: It does. I was just going to say that, from that perspective, it’s really wide. We here at HP say time-and-time again that it’s the service perspective that makes sense, because if you address only the pockets, you only find a pocket for saving. It’s just as likely that, at some point, a cost or a risk may pop up somewhere else, because you're looking at only part of the picture.

When we talk about the whole notion of the service, we're really saying to look at the whole picture from that top-down perspective. That allows you to make sure to put out a fire, if you are saving money in some place, but that you're really saving it and not pushing it to a different place. That’s the perspective you don’t have, if you're looking at just from the infrastructure or from the view of "Here is a management tool I have to choose." You miss out from that perspective.

Gardner: Bob, moving back to this notion of a road map, what is that you need to do in order to come from virtualization as an endeavor and an activity with this new emphasis on getting to the cloud? What do you start thinking? How do you shift in your mentality?

Meyer: We've talked about looking at it from a top-down perspective, but there is bottom-up perspective and bottom-up work to be done. Rebecca ticked off a lot of these at the top of the discussion. She talked about looking at standardization, how that helps, and how you can start to pool and source infrastructure, when you standardize.

Then you start to understand the implications of shifting workloads, not losing specialty tools, and really getting to a point when you standardize. You could start to get to the point of managing a single infrastructure, understanding the costs better, and really be more effective at servicing and provisioning that. Standardizing has to happen in order to get there.

Everybody will have some combination of physical and virtual infrastructure.



We talked about virtualization as another element. I'm not just talking about the server and hypervisor itself. You have to really look across your infrastructure, at the network, server, and storage, and get to that level of convergence. How do I get those things to work together when I have to provision a new service or provide a service?

Most people know how to do the virtualized server stuff really well right now. They tend to see bottlenecks, maybe in provisioning the storage or connecting to the network. How do we get all those to flow seamlessly in harmony and really getting that virtualized infrastructure quickly, along with the physical infrastructure?

The third, or last, thing we look at is from the automation perspective, when you're looking to source something for a service or you're looking to pull assets together. Everybody will have some combination of physical and virtual infrastructure. So, how do I take action when I need a compute resource, be it physical or virtual?

How do I know what’s available? How do I know how to provision it? How do I know to de-provision it? How do I see it if that’s in compliance?" All those things really only come through automation. From a bottom-up perspective, we look at the converged infrastructure, the automation capabilities, and the ability to standardize across that.

Gardner: Are there any examples that you have about organizations that have gotten themselves ready to take the next step of virtualization? What’s been your experience? What may have been different for them than before, when they may have been looking at this a bit myopically?

Focal point

Meyer: I use virtualization as a focal point. It tends to be a series of maturity with virtualization. When most people start, they start with a server and hypervisor, and then they realize the storage and the IO and the automation has to come with it.

It’s that second step, when it’s gone beyond a server and hypervisor approach, and they've looked at the bigger picture, where the costs are actually being saved and pushed. The light goes on, and they say, "Okay, there is more to it than just virtualization and the server." You really do have to look, from an infrastructure perspective, at how you manage it, using holistic management, and how you connect them together.

I don’t think I've seen anybody who skips that first step at the server and hypervisor, but it really takes some time and maturity. Hopefully, at HP we can help make that progression faster, because we’ve worked with so many companies through this progression. But really it takes moving beyond the hypervisor approach, understanding what it needs to do in the context of the service, and then looking at the bigger picture.

Gardner: Rebecca, a similar question to you. Cloud computing isn’t just about providing services. It’s also being able to consume them well. Is there something going on for those companies that are already thinking about cloud that they should be then thinking about how to consume virtualized servers and services better?

Lawson: There's hardly a customer that doesn’t know that people in their organization are out there consuming cloud-based infrastructure services. That may be okay, but I think most IT organizations want to be aware and help govern what actually gets consumed.

There needs to be a governing entity, supported by tools and governance practices, that say what’s acceptable for the corporation and what’s not acceptable.



That’s hard to do, because it’s easy to have rogue activity going on. It’s easy to have app developers, testers, or even business people go out and just start using cloud services. That might be okay, but there also might be problems associated with that. So, there needs to be a governing entity, supported by tools and governance practices, that say what’s acceptable for the corporation and what’s not acceptable.

For example, you can get yourself in a lot of trouble, if you're consuming a service -- let’s say it’s a financial service -- and you, as a business person, don’t realize where your data lives. That could be problem from a corporate governance point of view, because where your data resides is important to a lot of organizations.

Sometimes, there are legal issues, and sometimes it has to do with the country that you live in. There are a lot of governance implications. People in the lines of business don’t always realize this, because that’s not their job. Their job is to get something done to execute a process or to get a certain result. They don’t take the time or have the understanding of all the implications of using some cloud service.

For sure, our customers are very interested in figuring out how can they put their arms around it, without seeming like they are trying to control everything, because that gives IT kind of a bad rep when they come in with a strong arm. There are definitely ways to do that.

Catalog of services

I
f IT is willing and able to step back and provide a catalog of all services that the business can access, that might include some cloud services. Maybe you have Amazon EC2 as one of the services that you provide that’s been pre-screened, and it’s appropriate for your particular organization. Or, maybe it’s appropriate for some people and some countries of your organization, but not others.

We think it’s important. We try to encourage our customers to use the tools, techniques, and the approach that says, "Let’s embrace all these different kinds of services, understand what they are, and help our lines of business and our constituents make the right choice, so that they're using services that are secure, governed, that perform to their expectations, and that don’t get them into trouble."

Gardner: It’s still early in this whole cloud discussion. We talked earlier about this hybrid model. There are not very many companies that I am aware of that are doing that, other than perhaps at a pilot level or maybe within the app-dev tool side of things.

Are there any examples that you are aware of, Rebecca, where that appreciation for the consumption and the governance has provided some benefits, and/or what would they be? Is there anything we can measure? I know that governance is a tough one to measure.

Lawson: What I'm seeing right now in customers is more of a softer measurement. For example, I was talking to a customer who knew that there was a lot of rogue activity going on. In their minds, it was rogue, because it wasn’t going through IT. They really wanted to have a way to encourage their stakeholders to use services from IT. So, they decided that in order to do that, they wanted to make it just as easy for appdev to secure a virtual instance from IT, as it was from Amazon.

Employees always want to do the right thing and now they had motivation to go back to IT and start using the internally provisioned infrastructure.



So, they worked on that, they put together about 10 different configurations that included storage, computing, network and all that stuff, and they made it available to the app developers. They said, "You can go outside for this stuff and pay for it, or you can use ours. By the way, if you use ours, we're going to be able to provision you just as fast, just as quickly. You are inside the firewall, and everything is cool."

They had a kind of pull mechanism, where they made it really easy for their constituents to use the services that were pre-approved. That’s really the right approach. The measurement of that is that, all of a sudden, they had an up-tick on their services. Employees always want to do the right thing and now they had motivation to go back to IT and start using the internally provisioned infrastructure.

That was a big win for them. All they did to do that was to look at the outside providers and looked at what kinds of promises, service level agreements (SLAs), and provisioning they use, and they just replicated that inside their shop. It worked really well.

Gardner: Right. A service is a service.

Lawson: There's no excuse not to do that these days, because the tools and technologies exist to allow you to do that. At HP, we’ve been doing that for many years. It’s not really brand new stuff. It’s new to a lot of organization that haven’t used it, but we’ve got a lot of experience in that area.

Gardner: Of course, the benefit of doing it through your own IT department is that you can go from test to dev in your production with a heck of a lot more ease than if you had to bring it in from a “rogue activity,” right?

Central governance

Lawson: That’s exactly right, and it may turn out that 30 percent of your infrastructure actually goes out to a third-party, like an Amazon, EDS, or some other third-party. But, the idea is that you want a central governance of what’s okay and what’s the right way to go, based on the value equation, not just based on the cost equation. That’s the direction we're steering our customers in.

Gardner: On this progression -- on the road map from tactical to strategic thinking and behaving more like a cloud provider and consumer -- it seems that there is a behavioral, cultural best practices aspect to this as well. Do those organizations that are seeking this need to plug into their road map something like ITIL, or a shared services approach?

Lawson: Absolutely. If you look at what ITIL Version 3 talks about, it’s all about service strategy and the lifecycle of each service. So, ITIL Version 3 is really important, underpinning to this whole idea.

Gardner: Let's look at the future a little bit,. With cloud-bursting benefits, I can spin up instances of a runtime for an adaption or a dataset, maybe even some network services, telephony, communication services, asynchronous communications, or collaboration. If I can start to do that, I'm going to need to manage this public/private divide somehow.

The catalog drives the right kind of discussion. Once you have that in place, you can start to make changes around what you offer out to the business and, by implication, what you don’t offer.



I wonder what HP is thinking about in terms of how to enable that. As you say, there are some of these aspects going on for years, but this whole notion of the hybrid crossing those boundaries is something a bit fresh.

Perhaps, you can describe what we might expect. I don’t expect to pre-announce products, but functionally what we should expect in terms of managing this hybrid capability.

Lawson: From a top-down approach, we encourage our customers to start immediately working on a service catalog. Because when you have a service catalog, you're forced into the right cultural and political behaviors that allow IT and lines of business to kind of sync up, because you sync up around what’s in the catalog.

It allows you to have that discussion of what’s really important and what’s not important. It also allows you to ferret out where are the squeaky wheels getting attention, but maybe they shouldn’t be. How can we better standardize our offerings? All that happens around the catalog.

So, the catalog drives the right kind of discussion. Once you have that in place, you can start to make changes around what you offer out to the business and, by implication, what you don’t offer. Once you have a services catalog, it might have services from the cloud, some internal services, mainframe services, or whatever., it’s going to be a whole mixed bag.

Control, manage, measure

Then you can start to control, manage, and measure across that hybrid ecosystem with standard IT management tools. For example, if you want to measure the performance and availability of every service -- whether it’s being served up from in-house, you're getting it from a managed service provider, or it’s a cloud service -- you want to have the same performance availability and security metrics on every single service.

Once you're organized, the organizing principle is the technology-enabled service. Then you can be consistent. You can say, "This external email service that we're using is really performing well. Maybe we should look at some other productivity services from that same vendor." You can start to make good decisions based on quantitative information about performance availability and security.

What you can expect to see from HP is continuing along that line of reasoning that says, "What are the right tools that IT can use to have full transparency into all of the elements of an SLA, regardless of where that service comes from, because we know that services are going to come from lots of different types of delivery models, lots of different form factors and technology attributes. And so that consistent transparency from an SLA point of view is really important and you'll see a lot more happening in that area from HP.

When you talk about standardization, it’s not just standardizing on a specific type of server or a specific management tool. It’s really standardizing on how you measure the services.



Gardner: How about you, Bob? You mentioned standardization a couple of times. How do we take standardization across cloud provider boundaries? Is there a neutrality or a certain set of agreements or contracts or de facto standards that need to happen there?

Meyer: Right, we’d go back to something that Rebecca said the about the importance of your internal processes. A lot of people talk about ITIL. They think about change management and change control. All of those elements really talk of standardization. Even the catalog Rebecca was talking about forces standard measurement, so you can really do an apples-to-apples comparison.

When you talk about standardization, it’s not just standardizing on a specific type of server or a specific management tool. It’s really standardizing on how you measure the services. In order to do that, you do need certain fundamentals in place. You need to have a service catalogue. It’s critical.

People are also talking about a configuration management database (CMDB) or a configuration management system (CMS) that holds all that information, so you can get those unified views.

So, yes, it's standardized contracts, but importantly your measurements standardized across whatever you agree that commonality is across the different service sourcing type. You have to come down to an apples-to-apples comparison and make sure that you are measuring and monitoring in the same way so that you can compare the values.

Common measurements

A
lot of times, what we see is people have a set of measurements from managed services, another set for the traditional source services, and now even a third way of billing or measuring for virtualized services. You can’t really start to do that comparison, until you get to a common set of measurements and understandings across services. When we talk about standardization, it’s definitely much more than just the standardizing servers, although that’s important, and then standardizing on the storage.

Gardner: Let me drill down on the configuration data comment. It seems to me that moving across cloud service sets -- whether it’s internal, external or both -- many of the underlying services might be standardized or similar. It’s really going to change and be integral to an application activity, a user, or a process, with configuration information about the integration, about the application, the users, access, control, and so forth.

Does it make sense for organizations to get their configuration management act together now, as a precursor to SOA or standardization around virtualization, as a really important necessary step to take advantage of cloud.

Meyer: I wouldn’t want to say that that you have to stop everything you do and re-architect a CMDB that cuts across everything, but hopefully if people have been following and implementing ITIL for the last couple of years, they have a good majority of data.

. . . Then you have to rely on the human factor to pull all that information together into a common report and come up with common measurements and methodologies. That takes time and introduces human error.



Most people, at this point, have a CMDB or a CMS that federates from different data sources. It is important, if you want to measure from the service and you want to understand your options of insourcing/outsourcing, that you have that set of data. If you have it, federate it in the single repository with common measurement. It makes that job much easier and it makes you more agile.

If you don’t, then you have to rely on the human factor to pull all that information together into a common report and come up with common measurements and methodologies. That takes time and introduces human error. It is possible to do without, but that possibility means more expense and more risk, because you are open to non-compliance and lower agility.

Gardner: Rebecca, perhaps you are including this in your discussion about catalog, but let’s just take a quick pause and look at the configuration management issue if you don’t mind.

Change management

Lawson: If you start from the catalog, when somebody makes a selection -- let’s say you choose to on-board an employee -- all of the things that have to happen from that point onwards need to go and hit change management CMDB. The reason you are doing configuration management is to have the service of a change, because every time you make a change, whether it’s pre-approved or it has to go through the change advisory board, you're exposing yourself to something going wrong.

That’s why you want change management as practice, so that you know what configuration items you have. You know why they're important. You know what they're attached to, so that when it is time to make a change, that happens in an organized way and with full transparency.

I sometimes call change and configure "the artery system," because you can’t really do anything, unless you have the whole system well enough managed, so that, when a change happens, if you’ve got full transparency into what occurs, the good, the bad, and the ugly, it’s only then that you can either roll back, measure success, or replicate success by doing successful changes.

Change in config is at the heart of the whole equation. Regardless of this, cloud services are not cloud services. Every time you make a change to your policies about consuming an external service, that should go through change as well, which then hits config. I don’t know if that answered your question.

Gardner: I think it’s an affirmative.

Lawson: Yes.

Gardner: We’ve been learning a little bit more about the road map from virtualization strategies toward more cloud-like benefits, some of the necessary steps, and how things can be looked at with that foresight of, "I'm going to want to do other cloud like activities later."

Helping us sort through this road map to move from virtualization to cloud computing, we have been joined by Rebecca Lawson, director of Worldwide Cloud Marketing at HP. Thank you, Rebecca.

Lawson: Thank you very much, Dana.

Gardner: Also Bob Meyer, worldwide virtualization lead for HP Technology Solutions Group. Thanks again, Bob.

Meyer: Thanks to you.

Gardner: This is Dana Gardner, principal analyst at Interarbor Solutions. You’ve been enjoying 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.

Get a free copy of Cloud for Dummies courtesy of Hewlett-Packard at www.hp.com/go/cloudpodcastoffer.

Transcript of a sponsored BriefingsDirect podcast on what enterprise architects need to consider when moving from virtualization to cloud computing. Copyright Interarbor Solutions, LLC, 2005-2009. All rights reserved.