Interview: rPath’s Billy Marshall on How Enterprises Can Follow a Practical Path to Virtualized Applications

Transcript of BriefingsDirect podcast on virtualized applications development and deployment strategies as on-ramp to cloud computing.

Listen to the podcast. Download the podcast. Find it on iTunes/iPod. Learn more. Sponsor: rPath.

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 proper on-ramps to cloud computing, and how enterprises can best prepare to bring applications into a virtual development and deployment environment.

While much has been said about cloud computing in 2008, the use of virtualization is ramping up rapidly. Moreover, enterprises are moving from infrastructure virtualization to application-level virtualization.

We're going to look at how definition and enforcement of policies helps ensure conformance and consistency for virtual applications across their lifecycle. Managing virtualized applications holistically is an essential ingredient in making cloud-computing approaches as productive as possible while avoiding risk and onerous complexity.

To provide the full story on virtual applications lifecycle, methods and benefits, I'm joined by Billy Marshall, the founder of rPath, as well as their chief strategy officer. Welcome to the show, Billy.

Billy Marshall: Thanks, Dana, great to be here.

Gardner: There is a great deal going on with technology trends, the ramp up of virtualization, cloud computing, services-oriented architecture (SOA), use of new tools, light-weight development environments, and so forth. We're also faced unfortunately with a tough economic climate, as a global recession appears to be developing.

What’s been interesting for me is that this whole technological trend-shift and this economic imperative really form a catalyst to a transformative IT phase that we are entering. That is to say, the opportunity to do more with less is really right on the top of the list for IT decision-makers and architects.

Tell me, if you would, how some of these technology benefits and the need to heighten productivity fit and come together.

Marshall: Dana, we've seen this before, and specifically I have seen it before. I inherited the North America sales role at Red Hat in April of 2001, and of course shortly thereafter, in September of 2001, we had the terrible 9/11 situation that changed a lot of the thinking.

The dot-com bubble burst, and it turned out to be a catalyst for driving Linux into a lot of enterprises that previously weren't thinking about it before. They began to question their assumptions about how much they were willing to pay for certain types of technologies, and in this case it happened to be the Unix technology. In most cases they were buying from Sun and that became subject of a great deal of scrutiny. Much of it was replaced in the period from 2001to 2003 and into 2004 with Linux technology.

We're once again facing a similar situation now, where people, enterprises specifically, are taking a very tough look at their data center expenditures and expansions that they're planning for the data center. I don't think there's any doubt in people's mind that they are getting good value out of doing things with IT, and a lot of these businesses are driven by information technology.

At the same time, this credit crunch is going to have folks look very hard at large-scale outlays of capital for data centers. I believe that will be a catalyst for folks to consider a variable-cost approach to using infrastructures or service, perhaps platform as a service (PaaS). All these things roll up under the notion of cloud, as it relates to being able to get it when you need it, get it at variable cost, and get it on demand.

Gardner: Obviously, there's a tremendous amount of economic value to be had in cloud computing, but some significant risks as well. As we look at how virtualization increases utilization of servers and provide the dynamic ability to fire up platform and instances of run-time and actual applications with a stack beneath them, it really allows companies to increase their applications with a lower capital expenditure upfront and also cut their operating costs. Then, we can have administrators and architects managing many more applications, if it's automated and governed properly. So let's get into this notion of doing it right.

When we have more and more applications and services, there is, on one side, a complexity problem. There is also this huge utilization benefit. What's the first step in getting this right in terms of a lifecycle and a governance mentality?

Marshall: Let's talk first about why utilization was a problem without virtualization. Let's talk about old architecture for a minute, and then we can talk about, what might be the benefits of a new architecture if done correctly.

Historically, in the enterprise you would get somewhere between 15 and 18 percent utilization for server applications. So, there are lots of cycles available on a machine and you may have two machines running side-by-side, running two very different workloads, whose cycles are very different. Yet, people wouldn't run multiple applications on the same server setup in most cases, because of the lack of isolation when you are sharing processes in the operating system on the server. Very often, these things would conflict with one another.

During maintenance, maintenance required for one would conflict with the other. It's just a very challenging architecture to try to run multiple things on the same physical, logical host. Virtualization provides isolation for applications running their own logical server, their own virtual server.

So, you could put multiples of them on the same physical host and you get much higher utilization. You'll see folks getting on the order of 50, 70, or 80 percent utilization without any of the worries about the conflicts that used to arise when you tried to run multiple applications sharing processes on the same physical host with an operating system.

That's the architecture we're evolving towards, but if you think about it, Dana, what virtualization gives you from a business perspective, other than utilization is an opportunity to decouple the definition of the application from the system that it runs on.

Historically, you would install an application onto the physical host with the operating system on it. Then, you would work with it and massage it to get it right for that application. Now, you can do all that work independent of the physical host, and then, at run-time, you can decide where you have capacity that best meets needs of the profile of this application.

Most folks have simply gone down the road of creating a virtual machine (VM) with their typical, physical-host approach, and then doing a snapshot, saying, "Okay, now I worry about where to deploy this."

In many cases, they get locked into the hypervisor or the type of virtualization they may have done for that application. If they were to back up one or two steps and say, “Boy, this really does give me an opportunity to define this application in a way that if I wanted to run it on Amazon's EC2, I probably could, but I could also run it my own data center.”

Now, I can begin sourcing infrastructure a little more dynamically, based upon the load that I see. Maybe I can spend less on the capital associated with my own datacenter, because with my application defined as this independent unit, separate from the physical infrastructure I'll be able to buy infrastructure on demand from Amazon, Rackspace, GoGrid, these folks who are now offering up these virtualized clouds of servers.

Gardner: I see. So, we need to rethink the application, so that we can run that application on a variety of these new sourcing options that have arisen, be they on premises, off premises, or perhaps with a hybrid.

Marshall: I think it will be a hybrid, Dana. I think for very small companies, who don't even have the capital option of putting up a data center, they will go straight to an on-demand cloud-type approach. But, for the enterprise that is going to be invested in the data center anyway at some level, they simply get an opportunity to right-size that infrastructure, based upon the profile of applications that really need to be run internally, whether for security, latency, data-sensitivity, or whatever reason.

But, they'll have the option for things that are portable, as it relates to their security, performance, profile, as it relates to the nature of the workload, to make them portable. We saw this very same thing with Linux adoption post 9/11. The things that could be moved off of Solaris easily were moved off. Some things were hard to move, and they didn't move them. It didn't make sense to move them, because it cost too much to move them.

I think we're going to see the same sort of hybrid approach take hold. Enterprise folks will say, “Look, why do I need to own the servers associated with doing the monthly analysis of the log files associated with access to this database for a compliance reason. And, then the rest of the month, that server just sits idle. "Why do I want to do that for that type of workload? Why do I want to own the capacity and have it be captive for that type of workload?"

That would be a perfect example of a workload where it says, I am going to crunch those logs once a month up on Amazon or Rackspace or some place like that, and I am going to pay for a day-and-a-half of capacity and then I am going to turn it off.

Gardner: So, there's going to be a decision process inside each organization, probably quite specific to each organization, about which applications should be hosted in which ways. That might include internal and external sourcing options. But, to be able to do that you have to approach these applications thoughtfully, and you also have to create your new applications. With this multi-dimensional hosting possibility set, if you will, it might. What steps need to be taken at the application level for both the existing and the newer apps?

Marshall: For the existing applications, you don't want to face a situation, in terms of looking at the cloud you might use, that you have to rewrite your code. This is a challenge that the folks that are facing with things such as Google's App Engine or even Saleforce's Force.com. With that approach, it's really a platform, as opposed to an on-demand infrastructure. By a platform I mean there is a set of development tools and a set of application-language expectations that you use in order to take advantage of that platform.

For legacy applications, there's not going to be much opportunity. For those folks, I really don't believe they'll consider, "Gee, I'll get so much benefit out of Salesforce, I'll get so much benefit out of Google, that I'm going to rewrite this code in order to run it on those platforms.

They may actually consider them for new applications that would get some level of benefit by being close to other services that perhaps Google, or for that matter, Salesforce.com might offer. But, for their existing applications, which are mostly what we are talking about here, they won't have of an opportunity to consider those. Instead, they'll look at things such as Amazon's Elastic Compute Cloud, and things that would be offered by a GoGrid or Rackspace, folks in that sort of space.

The considerations for them are going to be, number one, right now the easiest way to run these things in those environments is that it has to be an x86 architecture. There is no PA-RISC or SPARC or IBM's Power architecture there. They don't exist there, so A, it's got to be x86.

And B, the most prevalent cases of applications running in these spaces are run on Linux. The biggest communities of use and biggest communities of support are going to be around Linux. There have been some new enhancements around Microsoft on Amazon. Some of these folks, such as GoGrid, Rackspace, and others, have offered Windows hosting. But here's the challenge with those approaches.

For example, if I were to use Microsoft on Amazon, what I'm doing is booting a Microsoft Amazon Machine Image (AMI), an operating system AMI on Amazon. Then I'm installing my application up there in some fashion. I'm configuring it to make it work for me, and then I'm saving it up there.

The challenge with that is that all that work you just went through to get that application tested, embedded, and running up there on Amazon in the Microsoft configuration that Amazon is supporting is only useful on Amazon.

So, a real consideration for all these folks who are looking at potentially using cloud are saying, "How is it that I can define my application as a working unit, and then be able to choose between Amazon or my internal architecture that perhaps has a VMware basis, or a Rackspace, GoGrid, or BlueLock offering?" You're not going to be able to do that, if you define your cloud application as running on Windows and Amazon, because that Amazon AMI is not portable to any of these other places.

Gardner: Portability is a huge part of what people are looking for.

Marshall: Yes. A big consideration is: are you comfortable with Linux technology or other related open-source infrastructure, which has a licensing approach that's going to enable it to truly be portable for you. And, by the way, you don't really want to spend the money for a perpetual license to Windows, for example, even if you could take your Windows up to Amazon.

Taking your own copy of Windows up there isn't possible now. It may be possible in the future, and I think Microsoft will eventually have a business, whereby they license, in an on-demand fashion, the operating system as a hosting unit to be bound to an application, instead of an infrastructure, but they don't do that now.

So, another big consideration for these enterprises now is do I have workloads that I'm comfortable running on Linux right now, so that I can take a step forward and bind Linux to the workload in order to take it to where I want it to go.

Gardner: Tell us a little bit about what rPath brings to the equation?

Marshall: rPath brings a capability around defining applications as virtual machines (VMs), going through a process whereby you release those VMs to run on whichever cloud of your choosing, whether a hypervisor virtualized cloud of machines, such as what's provided by Amazon, or what you can build internally using Citrix XenSource or something like VMware's virtual infrastructure.

It then provides an infrastructure for managing those VMs through their lifecycle for things such as updates for backup and for configuration of certain services on the machines in a way that's optimized to run a virtualized cloud of systems. We specialize in optimizing applications to run as VMs on a cloud or virtualized infrastructure.

Gardner: It seems to me that that management is essential in order not to just spin out of control and become too complex with too many instances, and with difficulty in managing the virtual environments, even more so than the physical one.

Marshall: It's the lack of friction in being able to quickly deploy a virtualized environment, versus the amount of friction you have in deploying a physical environment. When I say "friction," I mean literally. With a physical environment somebody is going to go grab a server, slam it in a rack, hook up power networking, and allocate it to your account somehow. There is just a lot of friction in procuring, acquiring, and making that capacity available.

In the virtualized world, if someone has already deployed the capital, the physical capital, they can give you access to the virtual capital, the VM, very, very quickly. It's a very quick step to give you that access, but that's a double-edged sword. The reason I say it's a double-edged sword is because if it's really easy to get, people might take more. They might need more already, and they've been constrained by the friction in the process. But, taking more also means you've got to manage more.

You run the risk, if you're not careful. If you make it easy, low friction and low cost, for people to get machines, they will acquire the machine capacity, they will deploy the machine capacity, they will use the machine capacity, but then they will be faced with managing a much larger set of machine capacity than maybe they were comfortable with.

If you don't think about how to make these VMs more manageable than the physical machines to begin with, that friction can be the beginning of a very slippery slop toward a lack of manageability and risk associated with security issues that you can't get your arms around, just because of how broadly these things are deployed.

It can lead to a lot of excess spending, because you are deploying machines that you thought would be temporary, but you never take them back down because, perhaps, it was too difficult to get them configured correctly the first time. So, there are lots of challenges that this lack of friction brings into play that the physical world sort of kept a damper on, because there was only so much capacity you could get.

Gardner: It seems that having a set policy at some level of automation needs to be brought to the table here, and something that will cross between applications and operations in management and something that they can both understand. The old system of just handing things off, without really any kind of a lifecycle approach, simply won't hold up.

Marshall: There are a couple of considerations here. With these things being available as services outside of the IT organization, the IT organization has to be very careful that they find a way to embrace this with their lines of business. If they don't, if they say no to the line-of-business guys, the line-of-business guys are just going to go swipe a credit card on Amazon and say, "I'll show you what no looks like. I will go get my own capacity, I don't need you anymore."

We actually saw some of this with software as a service (SaaS), and it was a very tense negotiation for some time. With SaaS it typically began with the head of sales, who went into the CEO's office, and said, "You know what? I've had it with the CIO, who is telling me I can't have the sales-force automation that I need, because we don't have the capacity or it's going to take years, when I know, I can go turn it on with Salesforce.com right now."

And do you know what the CEO said? The CEO said, “Yes, go turn it on.” And he told the CIO, "Sit down. You're going have to figure out a way to integrate what's going on with Salesforce.com with what we're doing internally, because I am not going to have my sales force constrained."

You're going to see the same thing with the line-of-business guys as it relates to these services being provided. Some smart guy inside Goldman Sachs is going to say, "Look, if I could run 200 Monte Carlo simulation servers over the next two days, we'd have an opportunity to trade in the commodities market. And, I'm being told that I can't have the capacity from IT. Well, that capacity on Amazon is only going to cost me $1,000. I'm taking it, I'm trading, and we're going to make some money for the firm."

What's the CEO going to say? The CEO isn't going to say no. So, the folks in the IT organization have to embrace this and say, "I'll tell you what. If you are going to do this, let me help you do it in a way that takes risk out for the organization. Let me give you an approach that allows you to have this friction-free access, the infrastructure, while also preserving some of the risk, mitigation practices and some of the control practices that we have. Let me help you to find how you are going to use it."

There really is an opportunity for the CIO to say, "Yes, we're going to give you a way to do this, but we are going to do it in a way that it's optimized to take advantage of some of the things we have learned about governance and best practices in terms of deploying applications to an operational IT facility."

Gardner: So, with policy and management, in essence, the control point for the relationship between the applications, perhaps even the relationship between the line-of-business people and the IT folks, needs to be considered with the applications themselves. It seems to me that you need to build them for this new type of management, policy, and governance capability?

Marshall: The IT organization is going to need to take a look at what they've historically done with this air-gap between applications and operations. I describe it as an air-gap, because typically you had this approach, where an application was unit-test complete. Then, it went through a testing matrix -- a gauntlet, if you will -- to go from Dev/Test/QA to production.

There was a set of policies that were largely ingrained in the mind of the release engineers, the build masters, and the folks who were responsible for running it through its paces to get it there. Sometimes, there was some sort of exception process for using certain features that maybe hadn't been approved in production yet. There's an opportunity now to have that process become streamlined by using a system. We've built one, and we've got one that they can codify and put these processes into, if you will, a build system for VMs and have the policies be enforced at the build time so that you are constructing for compliance.

With our technology, we enforce a set of policies that we learned were best practices during our days at Red Hat when constructing an operating system. We've got some 50 to 60 policies that get enforced at build time, when you are building the VM. They're things like don't allow any dangling symlinks, and closing the dependency loop around all of the binary packages to get included. There could be other more corporate-specific policies that need to be included, and you would write those policies into the build system in order to build these VMs.

It's very similar to the way you put policies into your application lifecycle management (ALM) build system when you were building the application binary. You would enforce policy at build time to build the binary. We're simply suggesting that you extend that discipline of ALM to include policies associated with building VMs. There's a real opportunity here to close the gap between applications and operations by having much of what is typically been done in installing an application and taking it through Dev, QA and Test, and having that be part of an automated build system for creating VMs.

Gardner: All right. So, we're really talking about enterprise application's virtualization, but doing it properly, doing it with a lifecycle. This provides an on- ramp to cloud computing and the ability to pick and choose the right hosting and and/or hybrid approaches as these become available.

But we still come back to this tension between the application and the virtual machine. The application traditionally is on the update side and the virtual machine traditionally on the operations, the runtime, and the deployment side.

So we're really talking about trying to get a peanut-butter cup here. It's Halloween, so we can get some candy talk in. We've got peanut butter and chocolate. How do we bring them together?

Marshall: Dana, what you just described exists because people are still thinking about the operating system as something that they bind to the infrastructure. In this case, they're binding the operating system to the hypervisor and then installing the application on top of it. If the hypervisor is now this bottom layer, and if it provides all the management utilities associated with managing the physical infrastructure, you now get an opportunity to rethink the operating system as something that you bind to the application.

Marshall: I'll give you a story from the financial services industry. I met with an architect who had set up a capability for their lines of business to acquire VMs as part of a provisioning process that allows them to go to a Web page, put in an account number for their line of business, request an environment -- a Linux/Java environment or a Microsoft .NET environment -- and within an hour or so they will get an e-mail back saying, "Your environment or your VMs are available. Here are the host names."

They can then log on to those machines, and a decentralized IT service charges the lines of business based upon the days, weeks, or months they used the machine.

I said, "Well, that's very clever. That's a great step in the right direction." Then, I asked, and “How many of these do you have deployed?" And he said, “Oh, we've got about 1,500 virtual machines deployed over the first nine months.” I said, “Why did you do this to begin with?”

And, he said, “We did it to begin with, because people always requested more than they needed, because they knew they would have to grow. So, they go ahead and procure the machines well ahead of their actual need for the processing power of the machine. We did this so that we feel confident that they could procure extra capacity on-demand, as needed by the group.”

I said, “Well, you know, I'd be interested in this statistic around the other side of that challenge. You want them to procure only what they need, but you want them to give back what they don't need as well.” He kind of looked at me funny, and I said, “Well, what do the statistics look back on the getbacks? I mean, how many machines have you ever gotten back?”

And, he said, “Not a one ever. We've never gotten a single machine back ever.” I said, “Why do you think that it is?” He said, “I don't know and I don't care. I charge them for what they're using.”

I said, “Did you ever stop to think that maybe the reason they're not giving them back is because of the time from when you give them the machine to the time that it's actually operational for them? In other words, what it takes them to install the application, to configure all the system services, to make the application sort of tuned and productive on that host -- that sort of generic host that you gave them. Did you ever think that maybe the reason they are not giving it back is because if they had to go through that again, that would be real pain in the neck?"

So, I asked him, I said, “What's the primary application you are running here anyway?” He said, “Well, 900 of these systems are tick data, Reuters' Ticker Tape data." I said, “That's not even useful on the weekends. Why don't they just give them all back on the weekends and you shut down a big hunk of the datacenter and save on power and cooling?” He said, “I haven’t even thought about it and I don't care, because it's not my problem.”

Gardner: Well it's something of an awfully wasteful approach, where supply and demand are in no way aligned. The days of being able to overlook those wasteful practices are pretty much over, right?

Marshall: There's an opportunity now, if they would think about this problem and say, “Hey. Why am I giving them this, let's say, this Linux Java environment and then having them run through a gauntlet to make it work for every machine, instead of them taking an approach where they define, based upon a system and some policies I have given them, they actually attach the operating system and they configure all of this stuff independent of the production environment. Then, at run-time these things get deployed and are actually productive in a matter or minutes, instead of hours, days, and months.

In that way, they feel comfortable giving me the capacity back, when they are not using it, because they know that they can quickly get the application up and running in the manner it should be configured to run very, very quickly in a very scalable way, in a very elastic way.

That elasticity benefit has been overlooked to date, but it's a benefit that's going to become very important as people do exactly what you just described, which is become sensitive to the notion that a VM idling out there and consuming space is just as bad as a physical machine idling out there and consuming space.

Gardner: I certainly appreciate the problem, the solution set, and the opportunity for significant savings and agility. That's to say, you can move your applications, get them up fast, but you will also, in the long-term, be able to cut your overall cost because of the utilization and using the elasticity to match your supply and demand as closely as possible. The question then is how to get started. How do you move to take advantage of these? Tell us a little bit more about the role that rPath plays in facilitating that.

Marshall: The first thing to do, Dana, is to profile your applications and determine which ones have sort of lumpy demand, because you don't want to work on something that needs to be available all the time and has pretty even demand. Let's go for something that really has lumpy demand, so that we can do the scale-up and give back and get some real value out of it.

So, the first thing to do is an inventory of your applications and say, “What do I have out here that has lumpy demand?” Pick a couple of candidates. Ideally, it's going to be hard to do this without running Linux. It needs to be a workload that will run on Linux, whether you have run it on Linux historically or not. Probably, it needs to be something written in Java, C, C++, Python, Perl, or Ruby -- something that you can move to a Linux platform -- something, that has lumpy demand.

The first step that we get involved in is packaging that application as an application that's optimized to be a VM and to run in a VM. One of rPath’s values here is that the operating system becomes optimized to the application, and the footprint of the operating system and therefore it's management burden, shrinks by about 90 percent.

When you bind an operating system to an application, you're able to eliminate anything that is not relevant to that application. Typically, we see a surface area shrinking to about 10 percent of what is typically deployed as a standard operating system. So, the first thing is to package the application in a way that is optimized to run in a VM. We offer a product called rBuilder that enables just that functionality.

The second, is to determine whether you're going to run this internally on some sort of virtualized infrastructure that you've have made available in my infrastructure through VMware, Xen, or even Microsoft Hyper-V for that matter, or are you going to use an external provider?”

We suggest that when you get started with this set, as soon as possible, you should begin experimenting with an external provider. The reason for that is so that you don't put in place a bunch of crutches that are only going to be relevant to your environment and will prevent the application from ever going external. You can never drop the crutches that are associated with your own hand-holding processes that can only happen inside of your organization.

We strongly suggest that one of the first things you do, as you do this proof of concept, is actually do it on Amazon or another provider that offers a virtualized infrastructure. Use an external provider, so that you can prove to yourself that you can define an application and have it be ready to run on an infrastructure that you don't control, because that means that you defined the application truly independent of the infrastructure.

Gardner: And, that puts you in a position where eventually you could run that application on your local cloud or virtualized environment and then, for those lumpy periods when you need that exterior scale and capacity, you might just look to that cloud provider to support that application in that fashion.

Marshall: That's exactly right, whereas, if you prove all this out internally only, you may come across a huge "oops" that you didn't even think about, as you try to move it externally. You may find that you've driven yourself down in architectural box canyon that you just can't get out of.

So, we strongly suggest to folks that you experiment with this proof of concept, using an external, and then bring it back internally and prove that you can run it internally, after you've proven that you can run it externally.

Gardner: Your capital cost for that are pretty meager or nothing, and then your operating cost will benefit in the long run, because you will have those hybrid options.

Marshall: Another benefit of starting external for one of these things is that the cost at the margin for doing this is so cheap. It's between 10 and 50 cents per CPU hour to set up the Amazon environment and to run it, and if you run it for an hour you pay the 10 cents, it's not like you have to commit to some pre-buy or some amount of infrastructure. It's truly on demand. What you really use is what you pay for. So, there's no reason from a cost perspective not to look at running your first instance, of an on-demand, virtualized application externally.

Gardner: And, if you do it in this fashion, you're able to have that portability. You can take it in, and you can put it out. You've built it for that and there is no hurdle you have to overcome for that portability.

Marshall: If you prove to yourself that you can do it, that you can run it in both places, you've architected correctly. There's a trap here. If you become dependent on something associated with a particular infrastructure set or a particular hypervisor, you preclude any use in the future of things that don't have that hypervisor involved.

Gardner: Another thing that people like about the idea of virtualizing applications is that you get a single image of the application. You can patch it, manage it, upgrade it, and that is done once, and it doesn't have to be delivered out to a myriad of machines, with configuration issues and so forth. Is that the case in this hybrid environment, as well, or you can have this single image for the amount of capacity you need locally, and then for that extra capacity at those peak times, from an external cloud?

Marshall: I think you've got to be careful here, because I don't believe that one approach is going to work in every case. I'll give you an example. I was meeting with a different financial services firm who said, “Look, of our biggest application, we've got -- I think it was 1,500 or 2,000 -- instances of that application running." And he said, “I'm not going to flood the network with 1,500 new machines, when I have to make changes to that.” So, we are going to upgrade those VMs in place.

We're going to have each one of them access some sort of lifecycle management capability. That's another benefit we provide and we provide benefits in two ways. One, we've got a very elegant system for delivering maintenance and updates to a running system. And two, since you've only got 10 percent of the operating system there you're patching one-tenth as often, because operating system is typically the catalyst for most of the patching associated with security issues and other things.

I think there are going to be two things happening here. People are going to maintain these releases of applications as VMs, which you may want to think of as a repository of available application VMs that are in a known good state, and that are up-to-date and things like that.

And in some cases whenever new demand needs to come on line the known good state is going to be deployed and they won't deploy it and then patch it after they deploy it. It will be deployed and it won't need patching. But at the same time, there will be deployed units that are running that they will want to patch, and they need to be able to do that without having to distribute, dump the data, backup the data, kill the image, bring a new image up and then reload the data.

In many cases, you're going to want to see these folks actually be able to patch in place as well. The beauty of it is, you don't have to choose. They can be both. It doesn't have to be one or the other.

Gardner: So that brings us back to the notion of good management, policies, governance, and automation, because of this lifecycle. It's not simply a matter of putting that application up, and getting some productivity from utilization, but it's considering this entire sunrise-to-sunset approach as well.

Marshall: Right, and that also involves having the ability to do some high-quality scaling on-demand to be able to call an API to add a new system and to be able to do that elegantly, without someone having to log into the system and thrash around configuring it to make it aware of the environment that it's supposed to be supporting.

There are quite a few considerations here, when you're defining applications as VMs, and you are defining them independent of where they run, you are not going to use any crutches associated with your internal infrastructure to be able to elastically scale up and scale back.

There are some interesting new problems that come up here that also are new opportunities to do things better. This whole notion of architecting in a way that is A, optimized for virtualization. In other words, if you are going to make it easy to get extra machines, you'd better make machines easy to manage, and you'd better make them manageable on the hypervisor that they are running on. And B, you need to have a way to add capacity in an elegant way that doesn't require folks logging in and doing a lot of manual work in order to be able to scale these things up.

Gardner: And then, in order to adopt a path to cloud benefits, you just start thinking about the steps across virtualization, thinking a bit more holistically about the virtualized environment and applications as being one and the same. The level of experimentation gives you the benefits, and ultimately you'll be building a real fabric and a governed best methods approach to cloud computing.

Marshall: The real opportunity here is to separate the application-virtualization approach from the actual virtualization technology to avoid the lock-in, the lack of choice, and the lack of the elasticity that cloud computing promises. If you do it right, and if you think about application virtualization as an approach that frees your application from the infrastructure, there is a ton of benefit in terms of dynamic business capability that is going to be available to your organization.

Gardner: Well, great. I just want to make sure that we covered that entire stepping process into adoption and use. Did we leave anything out?

Marshall: What we didn't talk about was what should be possible at the end of the day.

Gardner: What's that gold ring out there that you want to be chasing after?

Marshall: Nirvana would look like something that we call a "hyper cloud concept," where you are actually sourcing demand by the day or hour, based upon service level experience, performance experience, and security experience with some sort of intelligent system analyzing the state of your applications and the demand for those applications and autonomically acquiring capacity and putting that capacity in place for your applications across multiple different providers.

Again, it's based upon the set of experiences that you cataloged around what's the security profile that these guys provide? What's the performance profile that they provide? And, what's the price profile that they provide.

Ultimately, you should have a handful of providers out there that you are sourcing your applications against and sourcing them day-by-day, based upon the needs of your organization and the evolving capabilities of these providers. And, that's going to be a while.

In the near term, people will choose one or two cloud providers and they will develop a rapport on a comfortable level. If they do this right, over time they will be able to get the best price and the best performance, because they will never be in a situation where they can't bring it back and put it somewhere else. That's what we call the hyper cloud approach. It's a ways off, it's going to take some time, but I think it's possible.

Gardner: The nice thing about it is that your business outcomes are your start and your finish point. In many cases today, your business outcomes are, in some ways, hostage to whatever the platform in IT requirements are, and then that's become a problem.

Marshall: Right. It can be.

Gardner: Well, terrific. We've been talking about cloud computing and proper on-ramps to approach and use clouds, and also how enterprises can best prepare to bring their applications into a virtual development and deployment environment.

We've been joined by Billy Marshall, a founder and chief strategy officer at rPath. I certainly appreciate your time, Billy.

Marshall: Dana, it's been a pleasure, thanks for the conversation.

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

Listen to the podcast. Download the podcast. Find it on iTunes/iPod. Learn more. Sponsor: rPath.

Transcript of BriefingsDirect podcast on virtualized applications development and deployment strategies as on-ramp to cloud computing. Copyright Interarbor Solutions, LLC, 2005-2008. All rights reserved.

Webinar: IDC Research Shows SOA Adoption Deepens in Enterprises Based on Key Implementation Practices

Transcript of Oct. 14, 2008 webinar on SOA research and how companies are implementing SOA more strategically based on essential adoption best practices.

Listen to the podcast. Download the podcast. Access the Webinar. Learn more. Sponsor: Hewlett-Packard.

Download the IDC report "A Study in Critical Success Factors for SOA."

Introduction: Hello, and welcome to a special BriefingsDirect presentation, a podcast created from a recent Hewlett-Packard (HP) webinar on Service Oriented Architecture (SOA) adoption trends. The webinar examines recent findings and analysis from original IDC surveys and research into actual enterprise SOA use and their reported business outcomes.

We'll hear from executives at both IDC and HP on how SOA is rapidly increasing in its importance and value for developers, architects and IT strategists. The presentation is followed by a question and answer session from the live webinar audience.

Please now welcome the webinar moderator, BriefingsDirect's Dana Gardner.

Dana Gardner: Hello, and welcome to our live webcast, “Expanding SOA Adoption to Mainstream IT,” brought to you by HP and InfoWorld. I’m your moderator Dana Gardner, principal analyst at Interarbor Solutions.

Today we’re going to examine fresh research from IDC on SOA adoption patterns and what users of SOA identify as success factors. In other words, for those doing SOA right, what it is that led them there, and what is it that they’re doing that others can learn from, in terms of best practices and insight?

We’ll hear from Sandy Rogers, program director for SOA, Web services, and integration research at IDC. We’ll also hear from Kelly Emo, SOA product marketing manager for HP Software.

Now let's dig into SOA use today, and the adoption patterns that show how and why SOA is moving into mainstream IT. We’re seeing a move to a strategic SOA value that support business goals and not just SOA that supports IT goals, such as the benefits around code reuse or development agility.

We’re starting to see a great deal of movement to the strategic value of SOA, and that means moving toward the aspects that create the need for governance, develops SOA benefits across larger business processes, and starts to show the paybacks in terms of actual business outcomes.

What are the factors that determine the success of SOA, generating that strategic and business level payback? Let's now go to Sandy Rogers at IDC, and learn more about her research into success in a SOA world.

Sandra Rogers: Thank you, Dana. Hello, everyone. First of all, what we want to do is take a look at what has brought us to this period of time -- where we now need to create enterprise-level systems.

Right now, we’re seeing a lot of systems where their foundations are basically breaking, and we’re dealing with a mixture of different generations, different types of systems, different ways that they were developed, different technologies, and different ways that they are and continue to be procured. Enterprises are challenged to address new and changing business requirements, and that volatility of business change is increasing at very rapid rate.

Organizations are looking for much more consistency across enterprise activities and views, and are really finding a lot of competitive differentiation in being able to manage their processes more effectively. That requires the ability to stand across different types of systems and to respond, whether in a reactive mode or a proactive mode, to opportunities.

The types of individuals who are being served by these systems are different, and that’s because of the extended value change, new types of workers entering the workforce, and many different business models that require either some type of self-service capability, or even more of a high-touch personalized type of engagement and experience with systems.

What we’re finding is that, as we go to this generation, SOA, in and of itself, is spawning the ability to address new types of models, such as event-based processing, model-based processing, cloud computing, and appliances. We’re really, as a foundation, looking to make a strategic move. With that kind of structure, it's also balancing freedom.

So, moving on, what we see -- and this is a poll that was recently run by IDC this summer, primarily with mid- and large-sized organizations -- is that if they haven’t already adopted SOA, they are planning on it, and at greater levels of engagement. So, if it is not going to be "the" standard for most or all systems, it's important, and will be used for all new projects, or it's a preferred approach.

The issue is not necessarily deciding if they should go toward SOA. What we're finding is that for most organizations this is the way that they are going to move, and the question is just navigating how to best do that for the best value and for better success.

According to the same poll, what we show is the top IT objectives and challenges for SOA. We also asked for business objectives and IT objectives. What's different from past surveys that we've run is that the flexibility and agility to respond to changing business needs is actually number one now. In previous responses, that had been in the top tier of three, but not necessarily the first one.

What are most interesting are the top challenges in implementing SOA. All of our past studies reinforced that skills, availability of skills, and training in SOA continue to be a number one challenge. What’s really noticeable now is that setting up an SOA governance structure has reached the second most-indicated challenge. This is the top 3 of 18 options.

In the past you may have seen security or other technical elements, interoperability, or maturity of standards. What this is telling us is that we have reached another stage of maturity, and that in order to move forward organization will need to think about SOA as an overall program, and how it impacts both technology and people dimensions within the organization.

We find that when we ask this from a business objectives and challenges view, the business is looking at more efficient processes at greater levels of service and customer service throughout their entire environment. Some of their top challenges involve gaining agreement on what processes and services should exist, how to define those, and how to agree upon those, and also rallying individuals around support of budgeting and funding for SOA. This all points to an overall need to step up the ability to address this as a managed business discipline, versus a technology discipline.

Defining SOA Success

We wanted to look at how SOA's success is actually defined, even though SOA can have varying definitions amongst individuals, and what factors and practices in these organizations that are successful have the most impact. We wanted to see what tactics and technologies are being leveraged, and how they are being leveraged, and how they are being introduced and expanded within the enterprise.

Then, we wanted to see what other words of advice experienced leaders want to impart to others, as we are seeing a next wave of adopters that may be a little bit new to SOA, versus those that had come before.

So, with this study, we did primary research, mostly U.S.- and European-based companies who had successfully implemented enterprise SOA programs. Most of them had from two, to two-and-a-half, to over eight years of experience. Some of these companies actually had started their SOA endeavors at the turn of the century.

They’re senior level individuals with enterprise perspective and they’re primarily from the IT ranks. They also have had certain levels of experience that might range from CIO to enterprise architect, to quality manager. So, we got a broad-brush view, but most of these individuals were actually charged with, or were a core part of who was driving their SOA initiative in their organization.

This was based on a semi-structured interview format, so that while we wanted to capture some basic information about the overall IT environment structure, the SOA initiatives in particular, the technology, topology, the business goals, and drivers of the organization, we really won't have that broad brush view to present a context.

We also did this in a semi-structured way, in order not to skew the results and to unearth varying elements that may have influenced their success, despite what these individuals brought to the table. And, there was representation across various sized companies and industries sectors.

A few of the overarching trends reinforced what we have been seeing in some of our studies. We are indeed moving from project- and application-level SOA to more of a system and enterprise scale. And, the short- and long-term impact of SOA needs to be better understood and addressed. Enterprises need to manage the expectations of the individuals in the organizations as to how their roles will be impacted, and what kind of benefits they may get on a short term basis, versus that long term view and accumulation, and they need to try to balance strategy with tactics.

While technologies are key enablers, most of the study participants focused on organizational and program dynamics as being key contributors to success. Through technology, they are able to influence the impact of the activities that they are introducing into the overall SOA program.

That success can be defined in multiple dimensions, but rising to the top, we found that, in part because of their roles, the pervasiveness of SOA adoption in the enterprise was a key determinant of how they were looking at it, whether their programs were gaining traction in the right ways, and were being successful. They were achieving clear business results, and those that can be measured.

When we gathered all of this information, we had many different tactics and activities, and some of them started to become repetitive in our research. We created a framework of varying components, and elements that impacted success. Then, we aggregated these into seven key domains, as we call them.

Domains of SOA interest

While different elements can impact each different domain, and vice versa, it was interesting trying to think of a way to present his. All the different domains impact one another. Therefore, if you’re able to handle trust, you’re able to influence organizational change management effectiveness. If you’re able to address business alignment, then you’ll have much more success in understanding the impact on architecture and vice versa.

With this, it's much more of a network of different activities and components. The technologies interact on the network's foundation. When you really think about it, services is basically a network topology. SOA puts a wrapper around this environment, and tries to give it a foundation and a framework, for which it will function effectively.

The seven domains are: Business Alignment, Organizational Change Management, Communication, Trust, Scale and Sustainability, Architecture and Governance.

Now, we’re going to briefly go over these seven domains, and give some key trends that we discovered about how different activities and tactics can make each of these areas much more effective?

With business alignment we discovered that with these organizations and these individuals, SOA is truly understood as a business discipline. Now, many of them did admit that within their organization. They still have a way to go to educate, and incorporate SAO as more of a business view. It's often seen as more of an IT agenda, but that is starting to change. But, they themselves, in the way they have approached the issues, and the way that they are thinking about their program, see it as a business discipline.

That alignment of business to what is being incorporated in the program, services, and processes that are being created means the involvement of key individuals who have a keen understanding of the business. Sometimes, it might mean involving someone at a high enough level within a business division who can see how activities within that business division may be impacted or may impact other divisions, yet have enough understanding of some of the details around what transpires, what incorporates the business, what defines the business -- the elements and the processes -- and get them involved in the overall initiative.

These individuals also can influence others. They not only influence outcomes of what is actually being created, but they can actually influence the acceptance rate, the understanding of services of SOA within their network of individuals, and within the activities that they are involved in.

Many of these individuals can help with reflecting on what the current state of the environment is. That can actually help define what future state might need to be created. Think about the overall framework. I believe that you can get access to this and that HP is making it available to you for more detail. I know it's difficult to see here on the screen.

One of the factors highlighted here is indeed getting those individuals really involved, and helping them with determining a key business taxonomy, and vocabulary. It's very important that everyone get on the same page of how they are going to communicate with one another, and define that within an aligned business appropriate to what is being presented.

If we look at the next domain, organizational change management, one of the key factors we found is that many of these individuals did what they could do to ease the transition to ensure that individuals may not have overly complex requirements posed to them at the onset. They tried to figure out what the existing modus operandi was, incorporate what they could into that, and move the organization along. The key is to disseminate that knowledge, and give tools and different technologies that can help with that change, without imparting too much complexity, which disrupts, and/or impacts the goals that they are trying to achieve on a day-to-day basis.

This is very important, versus task initiatives that we have seen, where organizations put together a road map, expected the individuals to follow certain protocols, but really didn't think about how that would impact everything else that these individuals were involved in.

It also gets them to think outside the box across the enterprise. A way to do that is to show how different services are being created and what it looks like, giving them an overall understanding of the program, and driving cooperation through examples, and helping with their understanding by presenting them with concrete examples in their context. Then, they can start to envision what other types of services and processes it could be impacting, and who to get also involved if they want to build out this network impact.

One thing we found is that it's important to have that overall view of the program, of the enterprise, and to have key individuals as part of the central architecture team, the center of excellence, or whatever, work side-by-side with individuals on the different divisional development teams, the different business analysts involved. They can start to understand and impact the outcomes of initial projects.

Then through a train-the-trainer approach, they can get more individuals involved in utilizing what could be at their disposal. As time goes on and these organizations start automating more of the capabilities in the foundation for SOA, all of these different parties understand how to engage with the systems, take advantage of it, and then can start envisioning how to utilize them to their own success.

Successful communication proves essential

The next major domain is around communication. It was very important to these leaders that they were seen as a business leaders, as well as an IT leader. They were also evangelists, and politicians. They actually went out and did one-on-one discussions with key stakeholders. They would have discussions about what policies, protocols, and standards they were thinking about incorporating.

By the time those decisions needed to be agreed upon to gain that buy-in, a lot of that lobbying had happened behind the scenes, and there were a lot of lunch-and-learn type of sessions. That was really making those connections, and showing individuals how they could not only impact the success of the overall initiative, but also how they could actually gain some things from cooperating and drive that network effect.

In order to do that, a lot more visibility needed to be presented in a variety of different forms that these institutions used, and accessibility to this information is key. Trying not to have too many middlemen and trying to automate it, so individuals find what they needed, was very important.

Many of them had designed their own dashboards and wikis, different ways to present information on the overall program. They were thinking about the details, introducing things like registries and repositories from a more technical dimension. Engaging in more of a collaborative atmosphere really drove a lot and also allowed individuals to communicate with one another, and not always through the central team. This was very important.

Some smaller initiative may be able to run manually through a central group, but as soon as it started to extend, that's where they found that allowing different conversations and negotiations to happen, being able to have a potential policy consumer, finding various services, knowing how to engage with the service provider, and having that as automated as possible will not disrupt their daily routine. It will make it easier and will also capture all the necessary information to go forward, without having a lot of rework and lot of hand-holding. This was again very important that that kind of visibility and accessibility is so key.

That dovetails with the next domain, which is really about building trust, enabling cooperation, and building in a sense of security that these services are going to run and be available for someone to consume. Developers can now think about that loose coupling and drive more of a SOA architecture in what they’re developing. That sense of security is beyond just traditional security. It's performance. It's ensuring that the availability of that service is going to be there under load. There are lots of different concerns.

We found that many companies standardize security in the form of services embedded within the framework, foundation, and infrastructure that they had created for the SOA program. That, in and of itself, started alleviating the pressure on individuals to know exactly what security protocols to cover. They ensured identity rights and they could be protected, and mitigated their risks on inappropriate use of services.

They understood that this secure environment is important, and that the reputation of a service matters. That means validating that standards and policies were upheld and integrating what they could regarding testing and validation in the course of the lifecycle of developing their services. By the time a service was posted and available, that service could be depended on and there were no concerns about it. If this was being done manually or ad hoc, people found that they had different experiences.

One organization we interviewed found that over 50 percent of the services that were in production didn’t adhere to policies. As soon as they automated that and brought it up to 100 percent adherence, the network effect started to take over, regarding the consumption, use, and even the development of services.

The transparency and visibility into past behaviors and the history of the service is very important to individuals who are going to take that risk and take that step that they are not going to develop something on their own, but are going to reuse and capitalize on what is built out as this network of resources and services.

Architecture over technology

Of course, we can't talk about SOA without mentioning architecture, and what we kept hearing over and over again was that architecture should come first over technology. Many of these companies had to come up with reference architecture and had to prototype the technology and the reference architecture, so that it would be able to address reality.

In the past, I’ve heard, some of these enterprise architecture teams actually did, beyond a proof of concept, prototype the varying scenarios that were likely to serve in rolling out the architecture to more entities, more systems, more and system type.

So, setting the standards, setting the reference architecture, defining messages, schemas, and protocols -- more so than mandating the specific use of certain technologies -- was a real learning experience for these organizations. Large organizations, especially, may not be able to influence every technology that will be used or can't envision every single technology that will be introduced to the environment in the future.

What they needed to do was focus on all the architectural dimensions, best practices, and standards, and define those, so that when they needed to test whether technology could interact appropriately, they had much of this defined. That allowed that level of flexibility to flow through to the different divisions and teams. Thinking about architecture beyond technology, about the process of how you are dealing with setting up architecture, how you are engaging with architecture, and seeing it through it's different stages and lifecycle are very important.

Updating process and SOA technologies, vis-à-vis the overall IT environment, started to surface as a key concern in what needed to transpire. You can't treat SOA as a silo. You need to think about this as an overall environment that incorporates many different options. One of the major reasons people are moving to SOA is to take advantage of a heterogeneous mix of resources, whether internal to an organization, or external through an organization.

Thinking through those dynamics leads to the next domain, which is scale and sustainability, to prepare for that viral network effect and to automate and test for higher volumes of demands early on. We found some organizations that had either built some of their own technologies, or had sort of incorporated things that were available very early on in the decade. When it came time to scale out, and there was more pressure imposed on these systems, they really couldn’t handle the demand.

What we learned from them is to really make sure that you test that early. Even though you may not have the volume now, you may some day, and even one service could get hit by an unknown amount of consumption. Being able to prepare for that, and prepare your architecture, as well as your policies and your governance processes, to be more distributed and federated to prepare for more of a federated type of environment, means that these policies and technologies can scale out.

We found that it's a learning experience to get the right definition around a service, the right fit, and the right granularity. That's something that comes with experience, and you might need to go through a couple of iteration of services before people understand how to best keep volatility down on services, put the right level of abstracted tiers for processes and rules, and plan and test that you have the right levels. Then, you can scale out.

That may mean atomic services at some levels and more broad-grained services at others, and seeing how that impacts the infrastructure, and testing that out in all the different scenarios and dependencies that could exist.

Governance helps assure ongoing success

Last, but not least, the final domain, where we start impacting everyone, was the issue of bringing in proper governance. Thinking about it in balancing control with empowerment and driving consistency throughout the environment is very important. People needed to plan on the processes and ramp up the speed of development and deployment into production, until having that level of consistency was giving them huge amounts of business value, savings efficiencies, and opportunities in the market to differentiate and compete.

Making moves early to automate was a learning experience for a lot of these organizations that didn't do this. They found that they could have not only expanded their programs more effectively, but they could have mitigated their risks. They could have avoided a lot of rework, as they had automated governance processes earlier on, integrating it into the overall flow, as we stated before, and thinking about it not as a just “these are the things that need to be met and this is the information that needs to be captured.” It's really thinking about the processes.

What happens is that there are these exceptions, dealing with review committees that should be involved, determining the right roles and responsibilities, and sometimes that may mean amending what you have.

In other instances, it was creating anew. We found in other studies that a lot of organizations did not have strong governance. SOA almost forces these companies to do what they should have been doing all along around incorporating the right procedures around governance, and making that a non-intrusive approach.

If you make it too complex, no one is going to follow it. If you make it a mandated activity, without a lot of tools to help facilitate, it becomes a chore to do that non-intrusively. Also speaking to non-intrusive runtime governance, many of these organizations found that you really should have a centralized foundation of runtime governance incorporated into the fabric of the SOA architecture, and technology infrastructure.

From all the right monitoring and management around services, in particular portions of this network that's integrated together, you can gain that overall perspective and drive what’s necessary to move forward, both from a business goal perspective and from an IT topology perspective.

To quickly wrap up, here are some additional words of advice from the field. We found that enforcing policies, not putting off governance till later on, was very important, putting more efforts into business modeling, which many of these organizations are doing now. They said that they wished they had done a little bit more when thinking about the services that were created, focusing on preparing the architecture for much more process and innovation.

So, with that, I’d like to hand this off to Kelly Emo to speak on HP's offerings in the SOA space.

Kelly Emo: Thank you, Sandy. And good morning and afternoon, everyone. I’m just going to wrap up the webinar with about 10 minutes or so. I’m going to hit four main points that I think will dovetail nicely with what you heard today from Sandy Rogers, some great insights coming from customers who have “been there, done that,” and have been working with SOA for while. It’s real advice that we all can learn from.

I’m going to dive now into a little bit more context around why, if you’re doing SOA, now is absolutely the right time to be thinking about and working on a governance program. I’m going to share a few key governance-specific best practices that we've also gleaned from our customers who have been down the road of their SOA journey.

We’ll talk a little bit about the value of using an automated SOA governance platform, to help automate those manual activities and get you there faster. And, I’m going to wrap up with one customer success story, a customer who is almost complete with their SOA journey -- about 70 percent there -- and who sees significant business benefits through their investments in not only SOA, but SOA governance, and SOA management.

You heard from IDC the seven critical SOA success factors that came from this in-depth analysis of customers. The point that I want to reiterate here that was so powerful in this discussion is the idea that the seven domains are linked. By putting energy and effort in any one of them, you are setting yourself up for more success across the board.

What we are going to do now is drill down into that domain of governance. You’ll see as we talk through some of the key capabilities for SOA moving to the enterprise from a governance perspective, how it will help establish other success factors, like building our trust, or facilitating communication across IT silos, for example.

I’m just going to touch on this briefly. It's interesting here. HP has used this graphics for quite a while in talking about the need for governance, having a governance program that helps bring together the different IT stakeholders that play a part in the successful delivery and realization of business services that return the results that the business expects and that behave, so that they can be easily consumed, and reused for even more responsiveness and agility.

This graphic rings true even more now with the kind of pressures that our businesses and IT are under to realize the results of their investment in SOA faster with existing resources. What we’re seeing again and again with customers who have been implementing SOA and going down to the path of scaling it out, is that they have to invest in processes and best practices to not only deliver services, but to ensure that the services are of the highest quality, that they can be managed over time, and that policies are consistently applied, so that we can handle events like change and new consumption in a way that delivers the result that we expect.

We see many of our customers now crossing the enterprise scalability divide with their SOA, looking to incorporate SOA into their mainstream IT organizations, and they’re seeing the benefits of that initial investment in governance help them make that leap.

So why invest in SOA governance now? It's an interesting question I’ve been getting a lot lately. “Hey, you know, we’re under a lot of economic pressure, budgets are tight, there's fewer resources to do the same work.” This sounds counter-intuitive, absolutely, but this is the right time to make that investment in SOA governance, because the benefits are going to pay off significantly.

SOA governance is all about helping IT get to the expected business benefits of their SOA. You can think of SOA governance, in essence, as IT's navigation system to get to the end goal of SOA. What it's going to help IT do, as they look to scale SOA out, is to more broadly foster trust across those distributed domains. It's going to help become a catalyst for communication and collaboration, and it's going to help jump-start that non-expert staff.

You may recall that Sandy mentioned one of the biggest challenges with SOA is building out the education and expertise among the staff. If governance can assist in shrinking that learning curve, enable IT organizations to understand the unique attributes of SOA and what process is need to be applied to successfully realize their SOA goal, that will help accelerate the transformation that needs to occur from the SOA perspective.

The thing that's key about governance is that it helps integrate those silos of IT. It helps integrate the folks who are responsible for designing services with those who actually have to develop the back end implementations and with those who are doing the testing of performance and functionality. Alternately, it integrated them with the organizations that are responsible for both deploying the services and the policies and integration logic that will support accessing those services.

So, governance becomes the catalyst for integrating these silos and facilitating communication. One of the keys, one of the best practices we are seeing across these customers, is that they approach governance from a lifecycle perspective. They are not just thinking of one aspect, but they are actually thinking of all the different collaboration points, all the different key decisions that need to be made, as a service goes from initial concept, into its design, into the development organizations that are responsible for delivering the implementations, out into the QA organizations that are responsible for defining the requirements for testing aspects of those services.

This includes the functional test, the performance test, the security test, and then out into the operational teams. These teams will be responsible for deploying services into the network, and understanding the implications on the stacks, and data sources, services access, and those that are responsible for deploying policies, such as authentication policies, authorization policies, the protocol mediations, and all the way back into the change process.

On ramps to governance

I'm not saying that an organization has to automate and create a complete governance infrastructure for all aspects of the lifecycle on day one. Certainly, there’s going to be the starting point that's going to make the most sense, based on the organization's maturity. Maybe the first thing to bite off is automating how organizations can get visibility of services and putting some automated policy checks in place on the design side for testing supportive standards and interoperability.

By keeping a perspective on lifecycle governance, your organization can be primed and ready to handle SOA, as it scales, as more and more services go into production, and more and more services are deemed to be ready for consumption and reuse into new composite applications.

The key is to keep a service lifecycle governance perspective in mind, as you go about your governance program, and automation is key. Sandy touched on this, and my intent here is not to talk through all aspects of this slide, but just to show you that there are a number of different aspects of governance that can be automated. If they are, that will have significant efficiency pay off downstream.

Automating policy compliance can bring a huge pay off. Sandy mentioned an example where a customer went into their governance program assuming that people were doing the right thing and found initially that fewer than 50 percent of the services being built were actually in compliance with the design policies that they have established to meet their corporate and IT objective.

Automation that will ensure that those issues can be caught quickly, and the collaboration and processes can be put in place to affect that behavior, and alternately work into that network effect that Sandy talked about can not only be in compliance, but also be something to brag about.

This next slide makes a point that I think is important here. I talk to a lot of folks about SOA. When you talk about a service lifecycle, it's very different than a traditional application lifecycle. It builds upon the concept of an app lifecycle, where you have a planning, building, testing, deploying, and changed cycle, but you also have the impact of consumption. Those are the consuming services and will have a lifecycle of their own.

It involves planning what services they are going to consume in the building out of the composite application, locating those services, engaging in a contractual relationship with the service provider, and alternately testing and delivering that composite application. Then, if there is a change on either side of the equation, if there is a change to the underlying service or a change to the composite application that, in turn, impacts, both the service and the composite application from a expectations perspective and, potentially, in performance and quality perspective.

The SOA lifecycle can actually be thought of as concentric circles. It's an iterative, living, breathing thing, and that's why service lifecycle governance is so key, to keep all these dependencies and the synthetic relationship, moving smoothly forward in terms of meeting its business objective over time, not just the initial deployment, but as both services and consumption patterns change. And governance is a powerful tool to manage this power, and complexity downstream.

So what I am going to show you next are a couple of key things you can do with the governance program to help you manage and scale. The first is really thinking about this idea of the service manager. I talked about the lifecycles of providing a service and consuming a service. A service manager is either a real or virtual person who is responsible for ensuring that the service is delivering against the goals of the business, not just at its initial deployment, but as different people are consuming it.

When I say a “virtual person,” I realize how funny that sounds. I don't literally mean a virtual person. What I mean is that it could be the service provider, or could be a committee of service providers, key service consumers, and maybe a line-of-business owner.

Manage the services like a service

What we are finding more and more now is that organizations are actually investing in a role known as service manager, someone who oversees the implication of not only delivering a service over time, but those that are consuming it. I see this as a best practice that can be supported by SOA governance, and which helps empower them by giving them a foundation to set up policies and have visibility in terms of how this service is meeting its objective and who is consuming the service.

Sandy talked a little bit about this as well. This is another best practice we are seeing mature customers that are being successful, and that's the way SOA governance deploys out there. That's bringing together the robust and well-developed processes around SOA governance and quality assurance, and creating a collaborative environment between those that are responsible for managing the entire testing process of new applications and services and those that are involved with the initial planning, with the design of services, and the governance of services.

You can actually get a dialog going between your enterprise architecture and planning teams, your development teams, and your testing teams, in terms of the expectations, and requirements right upfront, as the concept of the service is being ferreted out.

Get that communication occurring, so that everybody knows what are the key aspects we are going to test, how we are going to deliver it, what the expectations are, and what the policies are from a quality perspective that’s going to drive governance decisions downstream.

A really simple example comes from a customer who automated a very simple policy, which said that if a service has any critical or serious defects, we won’t allow it to be pushed into the staging environment, but rather we’ll flag it, bring it back into the testing process, and have it a discussion around how we’re going to mitigate those requirements. That doesn't sound like a lot of work, but it was important as the number of services scaled up to really automate that collaboration, and ensure that things didn't fall in the cracks.

Ultimately, it's about driving collaboration between the enterprise architecture and development team and the quality assurance team through automated governance, connected to quality. The same thing can be said about operations, by aligning and integrating the processes and knowledge that’s gleaned through the planning, and design processes, and the governance processes about how services are expected to behave once they go into deployment.

With the information that flows to the operations team, what we avoid is throwing a service over the wall, and then testing to figure it out. As a result, the SOA and the operational aspects of a service that ultimately get realized in production align with the original expectations that we are established.

You get the service behavior that was originally intended, and as your SOA scales and you get more and more services out there, this becomes essential. It keeps that line of communication seamless and flowing between the planning side and the delivery side, so that you get the behavior that meets the needs of the service consumers, and ultimately the business. And again, automated governance can help with this.

HP just recently announced the third generation of our automated governance platform, HP SOA Systinet. We’re positioning this as IT's navigation system for SOA. It’s designed at the core to guide our customers through their SOA journey by automating the governance aspects of the service lifecycle. This will ensure that the policies that are defined and automated, at the design, planning, and build side, as well as at the testing and run side, will map to the goals of the business in IT.

There are a number of functions inside Systinet designed to empower that concept of the service manager, supporting both parts of the lifecycle by providing a service, and the consumption of services, and supporting that collaboration between those responsible for providing services, and those who want to engage in a contractual relationship with them. Ultimately, the idea behind Systinet 3.0 is IT's objective in scaling out their SOA across their enterprise to realize the business value of their SOA investments faster, which is so important in today's environment.

Success stories from the field

Let's talk about a customer who has actually done this. This is the success story of a major European telecom provider. They’ve implemented approximately 70 percent of their SOA objective and right from the get-go, they made an investment in SOA governance. What they have seen over the last three years is an ROI of 327 percent, and it's really benefited them in four main dimensions.

First, they’ve been able to reduce the amount of downtime in the provisioning and delivery of new mobile subscribers services. A lot of this has to do with the fact that the services that are being delivered have been designed compliant to policies and have been tested and confirmed that they will deliver the behavior that was expected in terms of how they execute an operation.

The customer has also been able to increase customer retention, which has really resulted from two things, faster delivery of new services, and reduced downtime.

They've been able to reduce the time to market behind the delivery of new services, because of the timing of the communication flows, and ensuring interoperability and compliance.

And, they have seen an overall IT cost reduction of a significant amount of money, almost a million dollars, with their investment in SOA governance from the get-go.

Investing in SOA governance, as I mentioned at the very beginning of my presentation, while it may require a little investment upfront, can have a significant and powerful payoff downstream, when you go to move SOA out into the mainstream.

With that, I’m just about out of time, and I want to make sure that we have some time for Q and A, for both Sandy and myself. So, here is a pointer to where you can learn more, as both Dana and Sandy mentioned upfront. The IDC research is available on www.hp.com/go/soa, so you can download the reports and dig in to the specific detail behind what was shared with you today.

So, I’m going to turn it back to Dana and let him lead Q and A.

Gardner: Thank you, Kelly. Now that we've had a few questions, I’m going to direct the first one -- from me, actually -- to Sandy. I wanted to find out if there were any real surprises, any unexpected results, when you went out to the field to uncover SOA practices. Was there anything that caught you by surprise?

Rogers: What was interesting was that when it comes to providing metrics around the SOA experience, we have got a long way to go. A lot of organizations knew about different approaches to SOA management in monitoring, and understanding dimensions around the environment well before they made those investments.

Then, they still followed the same pattern that we have seen in past generations of technology where, when we were first being introduced in the marketplace, people said they weren't going to make the same sort of mistakes. It seems that SOA is very much like other initiative.

What they are doing now is a really fast catch-up in finding a lot of immediate value from doing that. Part of that had to do with gaining the buy-in, justifying the investments. What most of these organizations are discovering is that the last mile is dealing with that funding hurdle, showing that kind of value. What they’re realizing is that if they have these kinds of capabilities, they would have been able to measure that value much earlier.

It's more of a word of advice that we were getting than it was a real surprise, but it's something that, as an industry watcher, you just sort of see. Also, a lot of these organizations are indeed starting to tackle Web 2.0, and mashups for other kinds of dimensions within their organization. They really see it as an overarching type of trend. They don't see these as separate technology initiatives, and that's actually a pleasant type of view and a surprise to me as an analyst to see that. That sort of holistic view is starting to take hold.

Gardner: Here's another question directed at Sandy. You mentioned that the automating governance is an important element. What best practices have you seen for convincing the management in these enterprises to start an automated governance program?

Rogers: I was mentioning that just a moment ago. The kind of visibility that you are able to give to management presents the information on what services are being incorporated. But, if those services are designed well, you can actually be able to track that to key performance indicators (KPIs) in business measures and understand how this can be justified and funded? That kind of visibility is very important.

The other thing with automating governance, and I think Kelly referred to this, is that you do not need to do it all at once. That really targets protecting the environment, being able to automate as much as possible, have standards services, and schema automatically populated in the tools, and have that shared metadata concept start to expand. So, whether you’re creating services from one tool or another, that metadata is being captured. As time proceeds, you act on that metadata in the form of what kinds of policies you need, and so the threshold you measure that you can achieve is an overall process.

Gardner: This is a question for Kelly. The European company mentioned that had the 320 percent-plus return on investment. Did they start their SOA with SOA management or governance? What best practices have you learned about when to start managing SOA?

Emo: It’s a very good question. In that particular scenario, they actually started first with management, because they were having downtime issues. What they found right away, as they started to instrument their SOA environment and understand where the issues were taking place, was the part of the problem was inconsistency, in terms of what the operational team understood they were supposed to do, when they provisioned out of service from a load balancing, a security, and an overall performance perspective.

They found very rapidly that if they put governance in place to start to capture those expectations back on the design side, and then communicate those expectations to operations, they were able to alleviate that gap. They are now at a point where they're automating a production deployment of services using templates that come out of the governance side. So, they’re seeing additional timesavings in terms of how quickly they can provision new mobile subscriber services to their customer base.

Gardner: Okay, I have another. I think it’s directed to Sandy. SOA is not happening in a vacuum. There are other major undertakings in IT departments and across enterprises of virtualization, cloud computing, data center consolidation have all have been quite prominent lately. The question is, how does SOA help or align with these other types of goals that IT is tackling?

Rogers: When it comes being able to support an effort like consolidation, the whole idea behind what a lot of people are doing with SOA is to try to consolidate on core functional and information elements, and then share those to the rest of the enterprise, and through different applications and systems.

So, it dovetails very nicely with consolidation. What a lot of organizations might do is try to consolidate first and then think about enabling with services. However, being able to expose varying parts of different systems and have that visibility into the core services and how they are being used can actually facilitate on both consolidation and modernization efforts.

When it comes to initiatives like cloud computing and virtualization, it's really thinking about the overall architecture, what kind of interfaces that you have, what kind of service needs to be supported in a virtualized environment being able to componentize, and modularize it, and allow for that necessary interoperability.

When you think about virtualizing systems, and when you think about that overarching idea of on-demand cloud computing, the first step is interoperability. We found a lot of even on-demand providers who didn't go down the Web services and services-oriented route, having to go back, and re-architect their solution. It's important to have that kind of interoperability facilitated on a standardized basis to enable those kinds of activities to proceed.

Gardner: I believe we’ve run out of time. I certainly want to thank our guests. We’ve been speaking with Sandra Rogers of IDC, and Kelly Emo of HP Software. This webcast is sponsored by HP Software and includes commissioned research from IDC.

You can get more information at www.hp.com/go/soa.

This is your moderator, Dana Gardner, principal analyst at Interarbor Solutions. Thank you all for joining the webcast.

You’ve been listening to a sponsored BriefingsDirect Podcast on SOA adoption patterns based on original research from IDC and HP. Thanks for listening and come back next time.

Download the IDC report "A Study in Critical Success Factors for SOA."

Listen to the podcast. Download the podcast. Access the Webinar. Learn more. Sponsor: Hewlett-Packard.

Transcript of Oct. 14, 2008 webinar on SOA research and how companies are implementing SOA more strategically based on essential adoption best practices.