Cloud Computing's Ultimate Value Depends Open PaaS Models to Avoid Applications and Data Lock-In

Transcript of a sponsored podcast discussion on open markets for cloud computing services and the need for applications that can move from one platform to another with relative ease.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: WSO2.

Get the free
"Cloud Lock-In Prevention Checklist"
here.

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 openness, portability and avoiding unnecessary application lock-in in the use of cloud computing.

A remaining burning question about the value and utility of cloud computing is whether applications and data can move with relative ease from cloud to cloud -- that is, across so-called public- and private-cloud divides, and among and between various public cloud providers.

For enterprises to determine the true value of cloud models -- and to ascertain if their cost and productivity improvements will be sufficient to overcome their disruptive shift to cloud computing -- they really must know the actual degree of what I call "application fungibility."

Fungible means being able to move in and out of like systems or processes, like a bushel of corn is fungible regardless of the market you buy it in. You can buy and sell a bushel of corn as a commodity across multiple markets and across multiple buyers: They know what they're getting.

But what of modern IT applications? Wouldn’t cloud models be far more attractive, and hybrid cloud models much more attainable, if applications (or instances of applications) were largely fungible -- able to move from cloud to cloud -- and still function?

Application fungibility would, I believe, create a real marketplace for cloud services, something very much in the best interest of enterprises, small and medium businesses (SMBs), independent software vendors (ISVs), and developers.

Fungible applications could avoid the prospect of swapping on-premises platform lock-in for some sort of cloud-based service provider lock-in and, perhaps over time, prevent being held hostage to rising cloud prices.

Today, we'll examine how enterprises and developers should be considering the concept of application fungibility, both in terms of technical enablers and standards for cloud computing, and also consider how to craft the proper service-level agreements (SLAs) to promote fungibility of their applications.

Here to discuss how application fungibility can bring efficiency and ensure freedom of successful cloud computing, we're now joined by Paul Fremantle, Chief Technology Officer and Co-Founder at WSO2. Welcome back to BriefingsDirect, Paul.

Paul Fremantle: Hi, Dana. Nice to see you again.

Gardner: We're also here with Miko Matsumura, author of SOA Adoption for Dummies and an influential blogger and thought leader on cloud computing subjects. Welcome back, Miko.

Miko Matsumura: Great to be here.

Gardner: So, as for this ability to bring an open vision of cloud computing, I think many people have a vision that it's perhaps a little bit more grand than the current reality. Let's go to you first, Miko. What's the difference between the popular vision of cloud computing and what's really available now? Is there much fungibility available?

Low fungibility

Matsumura: Fungibility is very, very critical, and one thing I want to emphasize is that the fungibility level of current solutions is very low. It's very logical to understand the history of this.

One of the things that really we need to understand about cloud computing is the word that you used in introducing the topic, which is this concept of "disruptive," the notion that you can have this kind of elasticity and the application can actually scale pretty radically within cloud a environment. This is one of the primary attractive aspects of entering into a cloud paradigm. So, that's a really neat idea.

The economics of upscaling and downscaling as a utility is very attractive. Obviously, there are a lot of reasons why people would start moving into the cloud, but the thing that we're talking about today with this fungibility factor is not so much why would you start using cloud, but really what is the endgame for successful applications.

The thing that's really intriguing is that, if your application in the cloud is unsuccessful and nobody uses it, it doesn’t really matter. You don’t need to move it. You don’t need to pay for it. In fact, the requirement that you don’t pay for an app that isn’t successful is a very good benefit to the business.

The area where we are specifically concerned is when the application is more successful than in your wildest dreams. Now, in some ways what it creates is almost an unprecedented leverage point for the supplier. If you're locked in to a very high-transactional, high-value application, at that point, if you have no flexibility or fungibility, you're pretty much stuck. The history of the pricing power of the vendor could be replicated in cloud and potentially could be even more significant.

In terms of a direct answer, fungibility, as its being offered today, is very poor and there are very few solutions in the market that offer a way for people to pragmatically move, once things start to take off and are successful.

Gardner: Paul Fremantle, do you also share this perception that there isn't very much fungibility? Why is it that people would allow themselves to get in a position where their applications are locked in, perhaps even more severely than had been in an on-premises deployment?

Fremantle: That's a really interesting question, Dana. The reality of cloud is that people are jumping on it, and I can understand why. In the current situation, many infrastructure teams and infrastructure providers within large organizations unfortunately have got to the point where it takes many months to provide a piece of hardware for a new app.

Just roll back a few years. Imagine it took 12 months to build the app, and it took 3 or 4 months to provide the hardware. That's fine. You have 8 months of developing, before you even need to go talk to the infrastructure guys and say, "I need some hardware for this."

Roll forward now, and people are building apps in a month, a week, or even a day, and they need to be hosted. The infrastructure team unfortunately hasn’t been able to keep up with those productivity gains.

Now, people are saying, "I just want to host it." So, they go to Amazon, Rackspace, ElasticHosts, Joyent, whoever their provider is, and they just jump on that and say,"Here is my credit card, and there is a host to deploy my app on."

No way out

The problem comes when, exactly as Miko said, that app is now going to grow. And in some cases, they're going to end up with very large bills to that provider and no obvious way out of that.

You could say that the answer to that is that we need cloud standards, and there have been a number of initiatives to come up with standard cloud management application programming interfaces (APIs) that would, in theory, solve this. Unfortunately, there are some challenges to that, one of which is that not every cloud has the same underlying infrastructure.

Take Amazon, for example. It has its own interesting storage models. It has a whole set of APIs that are particularly specific to Amazon. Now, there are a few people who are providing those same APIs -- people like Eucalyptus and Ubuntu -- but it doesn’t mean you can just take your app off of Amazon and put it onto Rackspace, unfortunately, without a significant amount of work.

As we go up the scale into what's now being termed as platform as a service (PaaS), where people are starting to build higher level abstractions on top of those virtual machines (VMs) and infrastructure, you can get even more locked in.

When people come up with a PaaS, it provides extra functionality, but now it means that instead of just relying on a virtualized hardware, you're now relying on a virtualized middleware, and it becomes absolutely vital that you consider lock-in and don’t just end up trapped on a particular platform.

One of the things that naturally evolved, as a result of the emergence of a common foe, is this principle of unification, openness, and alliance.

Gardner: Miko, we used to hear, going on 15 years ago, the notion of "write once, run anywhere," and that was very attractive in that time. But, I think what we're pointing out now is this ability to write once and deploy anywhere.

Maybe you could tell us how "write once, run anywhere" got going, because I know that at that time you were involved quite a bit with Java. Is there a sense of an offspring with cloud that we should look to in terms of this ability of fungibility?

Matsumura: That that's a very good and exciting parallel. On the development side, one of the things that naturally evolved, as a result of the emergence of a common foe, is this principle of unification, openness, and alliance.

It's a funny thing. It goes way farther back than even the ancient Greeks banding together to attack the Hittites at Troy, or the moon landing, where the United States was unified against the Russians. Every major advance in technology seems to be associated with everybody getting together in order to fight a common foe.

So, it's a very funny thing to see, because "write once, run anywhere" was really just a response, in Java terms, to the emergence of a dominant Microsoft, and in some ways it's an interesting emergent phenomenon.

Emergent players

The things to look at in the cloud world are who are the emergent dominant players and will Amazon and Google or one of these players start to behave as an economic bully? Right now, since we're in the early days of cloud, I don't think that people are feeling the potential for domination that would drive such a friendly, open behavior.

People who are thinking ahead to the endgame are pretty clear that that power will emerge and that any rational, publicly traded company will maximize its shareholder value by applying any available leverage. Because, if you have leverage against the customer, that produces very benevolent looking quarterly returns.

Gardner: Paul Fremantle, as I mentioned a little earlier in the set up, it's now the time when enterprises are starting to do their cost benefit analysis to ask what makes sense to keep close to their vests, within their control, and on-premises, and what might be more of a commodity function, application, or service that we would look to a cloud model.

But, it seems to me that you can't really take that without considering what degree of fungibility is involved. So, from your perspective, what are the potential economics here?

Fremantle: The economics are really interesting, and there are two ways of looking at them. A lot of people are looking at economics to say, "What is the internal cost of hosting? Can I move my CAPEX to OPEX and pay-per-use?"

Unfortunately, the big issue that comes in there, in most people's mind, is security. Can they move things to a public cloud because of security? Do they need a private cloud? Those are the simplistic first steps people go through as they start looking at cloud.

That's a very important aspect to look at when you move to cloud, both software as a service (SaaS) and the lower level functions, because you don't want to move something that you consider a core strength out to be a generic service.

Two other interesting angles need to be looked at. The first of those is about exactly what you just came up with, which is, what is my competitive advantage? Where do I particularly gain advantage over my competitors, and through which services?

That's a very important aspect to look at when you move to cloud, both software as a service (SaaS) and the lower-level functions, because you don't want to move something that you consider a core strength out to be a generic service.

So, if you think that your proprietary algorithms for customer relationship management (CRM) are absolutely vital to the success of your organization, the last thing you want to do is dump those and go to Salesforce.com. That's the first aspect.

The second aspect, is can you apply a portfolio model? Can you look at the aspects that are high value to you, the aspects which are business as usual, and , "Well, I can get not just basic cost improvement by moving my customer relationship to Salesforce, but can I still apply my own special sauce, even when I am using low-value cloud services?"

Simple example

This is just a really simple example. When WSO2 uses our CRM, which is a cloud-based provider, it's a Sugar On-Demand. We also have mashups, which we host in the cloud, that take those Sugar On-Demand systems and mash them up to provide extra value to us.

So, we're going beyond the basic commodity service and starting to get extra value. To me, that's one of the really cool things to think about in cloud. Not just thinking about private cloud, public cloud, and hybrid, but about, how can I mashup the internal secret sauce of my company, the stuff that gives me competitive advantage, with the low-cost commodity services on the web, and start to get more out of those?

Then, if you think about that in a fungible environment, where to move those pieces of code, how to host it, where to run it, then you start to get a dynamic IT organization that can drive business value for the company.

Gardner: Miko, I mentioned a little earlier the idea of a marketplace, where competition and freedom of movement and transparency would have a positive effect and allow the buyers of services to pick and choose freely. Therefore the onus goes to the provider to have the best service at the best price.

What I think Paul just described is an opportunity where processes are composed of services, some of which might be coming from a cloud of clouds, both on-premises and off. So, it seems as if an insidious movement toward inevitable cloud services involvement with your business processes is under way, but without necessarily recognizing that you might not be in a true marketplace.

To some extent, there already is a marketplace, but the marketplace radically lacks transparency and efficiency. It's a highly inefficient market.

Do you think that this is going to happen whether people plan for it or not, and should they therefore recognize that they need a marketplace now, rather than waiting for these services to be actually put well into use within their organizations?

Matsumura: It's always wonderful to get the clear thinking rationality that comes from analyzing things, like you guys. From my perspective, to some extent, there already is a marketplace -- but the marketplace radically lacks transparency and efficiency. It's a highly inefficient market.

The thing that's great is, if you look at rational optimization of strategic competitive advantage, then what Paul says is exactly the perfect mental model. "My company that makes parts for airplanes is not an expert in keeping PC servers cool and having a raised floor, security, biometric identification, and all kinds of hosting things." So, maybe they outsource that, because that's not any advantage to them.

That's perfectly logical behavior. I want to take this now to a slightly different level, which is, organizations have emergent behavior that's completely irrational. It's comical and in some ways very unfortunate to observe.

To create a little metaphor, in the history of large-scale enterprise computing, there has long been this tension between the business units and the IT department, which is more centralized. In a way, the tension Paul alluded to is this idea that the business department is actually the frustrated party, because they have developed the applications in a very short time. The lagging party is actually the IT department.

It's a bit like what happened to the actor Mel Gibson. He left his wife and his kids and went off with a mistress. In the metaphor, the seduction of the cloud, and how easy it is, is really a wonderful attraction for a man (or enterprise) who is ostensibly married to his own IT department. And, that IT department maybe is not so sexy as the cloud service.

Eventual disappointment

So, there is this unfortunate emergent property that the enterprise goes after something that, in the long run turns out to be very disappointing. But, by the time the disappointment sets in, the business executives that approved this entry point into the cloud are long gone. They've gotten promotions, because, their projects worked and they got their business results faster than they would have if they had actually done it the right way and actually gone through IT.

So, it puts central IT into a very uncomfortable position, where they have to provide services that are equal to or better than professionals like Amazon. At the same time, they also have to make sure that, in the long-term interest of the company, these services have the fungibility, protection, reliability, and cost control demanded by procurement.

The question becomes how do you keep your organization from being totally taken advantage of in this kind of situation, and how do you avoid the Mel Gibson-esque disappointment of whatever happened after you left your wife and went with your new sexy girlfriend?

Gardner: Are you sure you don’t want to bring up Tiger Woods at this point?

Matsumura: Another, perhaps more universally understood metaphor.

Gardner: I was thinking of multiple clouds in that case.

Well, we've certainly defined the problem. Now, what can we do about it? Clearly, if you have some good lawyers and some history of dealing with software licenses, you're going to be very careful about how you craft your SLAs.

What we are trying to do at WSO2 is exactly to solve that problem through a technical approach, and there are also business approaches that apply to it as well.

We would hope that your business units would do that as well as your IT department or within consultation with the IT department or at least the legal department. Clearly, one buttress or defense against lock-in and lack of a good relationship over time with your cloud provider would be the agreement, the legal bond.

Also, we mentioned standards. There need to be standards that people can point to and say, "You must adhere to this or I won't do business with you." They seem to be slow in coming.

Paul Fremantle, what else is left? Is there a technology perspective, a middleware perspective, or something that might borrow from the Java approach that could reduce the risk, but allow companies to also pursue cloud computing in an efficient market?

Fremantle: That’s a very nice lead in, Dana. What we are trying to do at WSO2 is exactly to solve that problem through a technical approach, and there are also business approaches that apply to it as well.

The technical approach is that we have a PaaS, and what’s unique about it is that it's offering standard enterprise development models that are truly independent of the underlying cloud infrastructure.

Infrastructure independent

What I mean is that there is this layer, which we call WSO2 Stratos, that can take web applications, web application archive (WAR) files, enterprise service bus (ESB) flows, business process automation (BPA) processes, and things like governance and identity management and do all of those in standard ways. It runs those in multi-tenant elastic cloud-like ways on top of infrastructures like Amazon, as well as private cloud installments like Ubuntu, Eucalyptus, and coming very soon, VMware.

Get the free
"Cloud Lock-In Prevention Checklist"
here.

What we're trying to do is to say that there is a set of open standards, both de facto and de jure standards, for building enterprise applications, and those can be built in such a way that they can be run on this platform -- in public cloud, private cloud, virtual private cloud, hybrid, and so forth.

What we're trying to do there is exactly what we've been talking about. There is a set of ways of building code that don’t tie you into a particular stack very tightly. They don’t tie you into a particular cloud deployment model very tightly, with the result that you really can take this environment, take your code, and deploy it in multiple different cloud situations and really start to build this fungibility. That’s the technical aspect.

Before I hand it back to you, I also want to talk about the business aspect, because technology doesn’t live on its own. One of the things that’s very important in cloud is how you license software like this. As an open source company, we naturally think that open source has a huge benefit here, because it's not just about saying you can run it any way. You need to then be able to take that and not be locked into it.

Our Stratos platform is completely open source under the Apache license, which means that you are free to deploy it on any platform, of any size, and you can choose whether or not to come to WSO2 for support.

We think we're the best people to support you, but we try and prove that every day by winning your business, not by tying you in through the lawyers and through legal and licensing approaches.

Of course, we think we're the best people to support you, but we try and prove that every day by winning your business, not by tying you in through the lawyers and through legal and licensing approaches.

Gardner: Miko, we seem to have quite a few technologies, open source, licenses, and standards in place for doing enterprise software. Can we overlay what is a longstanding approach to openness and interoperability in the traditional enterprise on to the cloud and, in a sense, virtualize the cloud services in such a way that we can still use the tools and middleware, so we don’t get locked in?

Matsumura: The great thing that Paul is articulating is essentially in regard to a sort of promise. What's exciting about the promise is that trust has some very interesting properties, which is that one of the things you need to do is to look at the will and the ability of the partner.

As a consumer of cloud, you need to be clear that the will of the partner is always essentially this concept of, "I am going to maximize my future revenue." It applies to all companies, and dare I say, WSO2 included.

WSO2, as a new entrant, as a disruptive entrant, and as a company that has built this incredible technology, is both from a technological perspective and contractual perspective, using open source and empowering the promise in a very manifest form by providing value-added services.

As Paul said, to prove to you each day that they are going to be the best support for your deployment, is almost like a laying down of arms. If the opponent is disarmed from the get-go, then their ability to stick you in the back, when you are not looking, is gone.

Thing that’s fascinating about it is that, when a vendor says "Believe me," you look to the fine print. The fine print in this case is the Apache license, which has incredible transparency.

Free to go

It becomes believable, as a function, being able to look all the way through the code, to be able to look all the way through the license, and to realize, all of a sudden, that you're free. If someone is not being satisfactory in how they're behaving in the relationship, you're free to go.

If you look at APIs, where there is something that isn’t that opaque or isn’t really given to you, then you realize that you are making a long-term commitment, akin to a marriage. That’s when you start to wonder if the other person is able to do you harm and whether that’s their intention in the long run.

Fremantle: This is really interesting. Let me tell you a slightly opaque story and I'll try and bring it back around to this.

The school I went to was run by monks, and one of these monks was 80 years old and had been in the monastery for 60 years or something. A reporter asked him, "Don’t you miss the freedom? Don’t you hate being locked-in to this monastery?" And the monk said something really interesting, "I choose every morning to remain here," he said.

Now, what’s WSO2's lock-in? What Miko has been trying to politely say is that every vendor, whether it’s WSO2 or not, wants to lock in their customers and get that continued revenue stream.

Our lock-in is that we believe that it's such an enticing, attractive idea, that it's going to keep our customers there for many years to come.

Our lock-in is that we have no lock-in. Our lock-in is that we believe that it's such an enticing, attractive idea, that it's going to keep our customers there for many years to come. We think that’s what entices customers to stay with us, and that’s a really exciting idea.

It's even more exciting in the cloud era. It was interesting in open source, and it was interesting with Java, but what we are seeing with cloud is the potential for lock-in has actually grown. The potential to get locked-in to your provider has gotten significantly higher, because you may be building applications and putting everything in the hands of a single provider; both software and hardware.

There are three layers of lock-in. You can get locked into the hardware. You can get locked into the virtualization. And, you can get locked into the platform. Our value proposition has become twice as valuable, because the lock-in potential has become twice as big.

Gardner: If you were to find a cloud provider that shared that long-term view, they don’t lock in, but their value proposition locks in, but for the right reasons, then the other cloud providers would be at a distinct disadvantage. So, do we have an opportunity now for a marketplace with an open middleware approach? And who are the cloud providers that should or perhaps will follow suit?

Fremantle: There is definitely an opportunity for an open market. I don’t want to go into naming names, but certainly you're bound to see in the cloud market a consolidation, because it is going to become price sensitive, and in price sensitive markets you typically see consolidation.

Two forms of consolidation

What I hope to see is two forms of consolidation. One is people buying up each other, which is the sort of old form. What would be really interesting, to circle back to what Miko said at the very beginning, is that it would be really nice to see consolidation in the form of cloud providers banding together to share the same models, the same platforms, the same interfaces, so that there really is fungibility across multiple providers, and that being the alternative to acquisition.

That would be very exciting, because we could see people banding together to provide a portable run time.

One of the really interesting things that you can get with fungibility is what we have in various markets, the idea of options, derivatives, and all of that. That would be cool. Imagine that you need to get your jobs done every Friday at lunchtime. And, Friday lunchtime is an expensive time to get your jobs done, because everybody needs compute time at Friday lunchtime.

In a truly fungible marketplace, you could buy options on having compute power on a Friday lunchtime at a certain price. If you don’t end up needing them, you could sell that at a higher price to someone else who does need it. Then, you start to get the real flexibility that markets provide in the computing industry. That would be pretty cool.

Gardner: So what about that Miko? If Paul’s vision holds out, at least a critical mass of cloud providers pull together and recognize they have a common destiny and that working together at a certain level will provide them a better future long-term, one that involves cloud fungibility.

People are branding electricity as wind power, renewable power, green power, and that has certain different economic dynamics. I think we will see similar things emerge in the cloud.

Then these options and derivative models, where you can basically eke out the most efficient way -- both from the supplier as well as the acquirer of the service, and incidentally probably reduce the carbon footprint across the board -- that would be a good outcome. Do you think that that’s pie in the sky? What needs to happen for that sort of vision to unfold?

Matsumura: What we're talking about is the inevitable market consequence of commoditization. So what Paul is speaking to is something a lot like the spot energy market, which already exists. You have direct conversion of one form of electricity, which is a sort of common denominator of power transport, into other forms of electricity. That’s a very interesting thing.

People are branding electricity as wind power, renewable power, green power, and that has certain different economic dynamics. I think we will see similar things emerge in the cloud.

The thing that really critical though is when this is going to happen. There is a very tired saying that those who do not understand history are doomed to repeat it. We could spend almost decades in the IT industry just repeating the things of the past by reestablishing these kind of dominant-vendor, lock-in models.

A lot of it depends on what I call the emergent intelligence of the consumer. The reason I call it emergent intelligence is that it isn’t individual behavior, but organizational behavior. People have this natural tendency to view a company as a human being, and they expect rational behavior from individuals.

Aggregate behavior

But, in the endgame, you start to look at the aggregate behaviors of these very large organizations, and the aggregate behaviors can be extremely foolish. Programs like this help educate the market and optimize the market in such ways that people can think about the future and can look out for their own organizations.

The thing that’s really funny is that people have historically been very bad at understanding exponential growth, exponential curves, exponential costs, and the kind of leverage that they provides to suppliers.

People need to get smart on this fungibility topic. I appreciate, Dana, that you're helping out with this. If we're smart, we're going to move to an open and transparent model. That’s going to create a big positive impact for the whole cloud ecosystem, including the suppliers.

Gardner: Paul Fremantle, Miko seems to think that this bright possible future could happen fast, or it could happen 30 years from now. How do we make sure it happens fast?

Isn’t there a built-in economic incentive? If there is a sufficient level of transparency, where the most efficient model becomes the most low-cost model, and therefore in a commoditized environment, it's where the most consumers go.

It's up to the consumers of cloud to really understand the scenarios and the long-term future of this marketplace, and that’s what's going to drive people to make the right decisions.

Is there something about WSO2’s approach and this notion of a shared destiny that almost guarantees it to be the lowest-cost provider? That is to say, wouldn't the commercial lock-in provider naturally have to be more expensive in this cloud environment?

Fremantle: There is that. One of the most important things, though, is what Miko just said about education. It's up to the consumers of cloud to really understand the scenarios and the long-term future of this marketplace, and that’s what's going to drive people to make the right decisions. Those right decisions are going to lead to a fungible commodity marketplace that’s really valuable and enhances our world, rather than dis-enhances it or makes it less good.

The challenge here is to make sure that people are making the right, educated decisions. From my perspective, obviously, I'd like people to try out WSO2 Stratos. But, at a higher level than that, I'd really like people to make informed decisions, when they choose a cloud solution or build their cloud strategy, that they specifically approach and attack the lock-in factor as one of their key decision points. To me, that is one of the key challenges. If people do that, then we're going to get a fair chance.

I don’t care if they find someone else or if they go with us. What I care most about is whether people are making the right decision on the right criteria. Putting lock-in into your criteria is a key measure of how quickly we're going to get into the right world, versus a situation where people end up where vendors and providers have too much leverage over customers.

Gardner: So, as you're doing that cost-benefit analysis and looking at these new models of cloud, you need to go beyond just the notion of doing away with CAPEX costs and move to OPEX cost. You need to think about what the long-term operating cost would be if there is a lock-in variable involved?

Fremantle: Not just the operating costs, but the flexibility, the freedom, and the ability to achieve your long-term objectives.

Gardner: Any last words on this notion of what to look for in terms of your cost-benefit analysis, Miko?

Worth exploring

Matsumura: Without being overly skewed in this discussion, WSO2 has provided a very interesting topic of conversation worth exploring. Smart organizations need to understand that it's not any individual's decision to just run off and do the cloud thing, but that it really has to combine enterprise architecture and ... cautionary procurement, in order to harness cloud and to keep the business units from running away in a way that is bad.

One of the culprits in this emergent behavior is the short lifespan of the CIO. The CIOs tend to job churn and they tend to be a little shortsighted about cutting costs. So, they get into an unholy alliance with business units that just want to slash and burn expenses for all existing IT. All of these unholy alliances create these negative choices.

In the long run, having a vendor agreement and relationship that forces them to be continuously pleasing to you and having agreements that you can walk away from at a moment's notice -- both technologically and from a business perspective -- is a completely new way of looking at this cloud market. WSO2 has a unique offering in this regard. So it’s certainly worth a look. That's my perspective.

Gardner: I'm afraid we'll have to leave it there. I want to thank you both very much. We've been discussing how enterprises and developers should be considering the concept of application fungibility, both in terms of technical enablers and standards, in order to best understand what their real potential cost over time would be for enjoying the best of cloud, but also looking out for the inevitable risks in a commercial environment, and avoiding potential lock-ins.

I want to thank our guests. We've been joined by Paul Fremantle, Chief Technology Officer and co-founder at WSO2. Thank you very much, Paul.

Fremantle: Thank you very much, Dana. It's been a fascinating discussion.

Gardner: And we've also been joined by Miko Matsumura, author of SOA Adoption for Dummies and an influential blogger and thought leader on cloud-computing topics. Thanks so much, Miko.

Matsumura: Great to be here. Thanks again for a great talk.

Gardner: This is Dana Gardner, Principal Analyst at Interarbor Solutions. You've been listening to a sponsored BriefingsDirect Podcast. Thanks and come back next time.

Get the free
"Cloud Lock-In Prevention Checklist"
here.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: WSO2.

Transcript of a sponsored podcast discussion on open markets for cloud computing services and the need for applications that can move from one platform to another with relative ease. Copyright Interarbor Solutions, LLC, 2005-2010. All rights reserved.

You may also be interested in:

• WSO2 Data Services Provide Catalyst for SOA and Set Stage for New Cloud-Based Data Models
  
  
• Open Source and Cloud: A Curse or Blessing During Recession? BriefingsDirect Analysts Weigh In
  
  
• WSO2 offerings add zest to Carbon 3.0 platform for BPM, cloud construction

Harvard Medical School Use of Cloud Computing Provides Harbinger for New IT Business Value, Open Group Panel Finds

Transcript of a sponsored podcast discussion from The Open Group's Boston Cloud Practitioners Conference on gaining business paybacks from cloud computing.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: The Open Group.

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 the business impact of cloud computing, coming to you from The Open Group Conference in Boston, the week of July 19, 2010.

We've put together a distinguished panel to explore practical implementations of cloud-computing models, and of moving beyond the hype and into the business paybacks from proper cloud adoption.

We'll tackle such issues as what stands in the way, safe and low-risk cloud computing, and what seems to be inhibiting IT leaders and/or business leaders as they seek to reduce the risk and exposure of their ongoing cloud efforts. We're also going to delve into a compelling example of successful cloud practices at the Harvard Medical School.

Here to help us better understand these best practices and proper precautionary steps on the road to cloud implementations that provide practical business improvements is our panel: Pam Isom, Senior Certified Executive IT Architect at IBM; Mark Skilton, Global Director, Applications Outsourcing at Capgemini; Dr. Marcos Athanasoulis, Director of Research Information Technology for Harvard Medical School, and Henry Peyret, Principal Analyst at Forrester Research.

Let me take my first question to you, Mark Skilton. I enjoyed your presentation earlier. The whole wellspring of interest, I might even say hype, in cloud computing wouldn’t happen if there wasn’t some dissatisfaction with the status quo. From your perspective, now that we have moved a little bit through a hype cycle with cloud computing, what are the resilient dissatisfaction elements of the status quo that are leading to a continued interest in cloud computing?

Mark Skilton: Thanks, Dana. I've answered this question a number of times before. What I typically say to people is that there are probably three areas that are persistent or continuing into the post-initial hype of the cloud -- I'm not saying Cloud 2.0 just yet.

There's the resilience of utility computing, the on-demand storage or the self-service component of computing. We're starting to see utility computing becoming much more common mainstream, so that it’s no longer a fad or an alternative to mainstream. We're seeing that sort of consistency.

To answer your question quickly, we're also seeing software as a service (SaaS), due to the economic conditions, taken quite seriously now, particularly targeted at specific business processes that we spoke of earlier, but also starting to become potentially more mainstream. Clearly, with Salesforce.com and others like that, we are seeing that starting to accelerate.

Different app store

The third one is a different type of app store. We're seeing application stores, particularly through the federal sector and government, to some extent in telecoms, and even in academic circles. We're seeing this idea that you certify into a catalog.

Gardner: Pam Isom, do you see a difference between the interest from the business leaders and the IT leaders, and why would that differ?

Pam Isom: From a business leadership and an IT leadership perspective, based on my customer experiences, I would say that it’s about the same. There is a tendency for IT leaders to want to share their capabilities. Business leaders just want to get the problem resolved -- tell us what you can do to fix our problems. They don’t specifically go out and request cloud, but there's a need for a business performance improvement, which leads to cloud enablement.

As far as what’s driving cloud as a solutions strategy is the need to improve business performance. If we can get solutions that will help drive business performance and business sustainability, the cloud is a good place for that.

Gardner: Henry, from your research and from some of my observations, do you share with me this notion that the business seems to be selling cloud computing to the IT department, and in only some cases the IT department is selling cloud computing to the business? What’s up with that?

Henry Peyret: That’s a good point, and I agree. Sometimes, when the business is trying to sell cloud computing, and IT is not really prepared to do that, they say no. They find tons of reasons to never go to the cloud.

The same also happens on the other side. Sometimes, IT is selling the cloud approach, and the business says, "No, I don’t want to take the risk. I have heard a lot about cloud, and I don’t want to take the risk."

The supposition is not so easy at the moment, but from an enterprise architect (EA) point of view, we should prepare for that. We should prepare to determine what are the elements that can migrate to the cloud, different types of cloud. Then, we should try to evangelize. The EA should be in between business and IT. That’s a good place to make a right choice and mitigate risks and choices.

Gardner: Of course, we've been talking for decades about alignment between IT and business. Do you think that cloud and the concept of cloud provides common ground for IT and business in a way that perhaps we hadn’t seen before? First to you Henry.

Wrong approach

Peyret: I don’t like to talk about IT and business alignment, I think that’s a bad approach. We should be in-sync. That means that every time the business changes, we should be prepared to be in-sync with the same thing.

We see the business changing faster than previously. So being aligned, you're always late, rather than being in-sync. That means that we should be able to anticipate where the competitors are going, and then we should propose several things to help the business at that point. Then, when the business is coming up, we should try to help. That’s where cloud is offering options, scenarios, and other choices to help existing or future problems.

Gardner: Pam, do you have a different outlook on what this common ground, the cloud, can provide?

Isom: You can’t produce cloud solutions in a vacuum. You won’t get any consumers. So, it’s a great venue for cloud providers to work with business stakeholders to explain and explore opportunities for valuable services.

Gardner: Mark, we've heard from several different speakers today that this notion of business process is where the cloud will pay off in the future. Even business process as a service has been raised. Does that provide the common ground? Maybe it’s not so much the delivery model of the cloud, but the fact that you focus on the process rather than systems or even applications?

Skilton: The fact that you are publishing this as a podcast and also there are people in this room probably doing Twitters and things, I think the cloud is already a common ground in a social sense. So, it's slow car crash, just waiting to happen. You've got to manage the situation with that. It’s already here, guys.

I'm very interested to hear from the business customers' perspective how cultural impact and change affects how that might need to accelerate into business adoption.

We're seeing two types of clouds: a social cloud, social networking, and also the business cloud, which is still forming in front of our eyes. It's less clear to know which direction that will go. The cultural and the consumer dynamics will drive that internally.

Gardner: Marcos, please tell us about your use-case and how cloud computing has been adopted at Harvard Medical School. Then, we'll also look to find out whether there was commonality there, or who was selling to whom.

Dr. Marcos Athanasoulis: Thank you. I'm delighted to be here. The business of Harvard Medical School is research, and this is true of course in big pharma and other organizations that are engaged in research. Similar to many industries, there is a culture that requires that for IT to be successful, it has to be meeting the needs of the users.

We have a particularly interesting situation. I call Harvard Medical School the land of a thousand CIOs, because, in essence, we cannot mandate that anyone use central IT services, cloud services, or other things. So that sets a higher standard for us, because people have to want to use it. It has to be cost-effective and it has to meet their business, research objectives.

We set out about five years ago to start thinking about how to provide infrastructure. Over time, we've evolved into creating a cloud that's a private cloud at the medical school.

User participation

Perhaps we'll touch on a little later some of the unique characteristics of biomedical research that have some particular constraints on the public cloud. But, we've been able to put in place a cloud that, number one, has user participation. This means that the faculty have and the researchers have skin in the game.

They can use the resources that are made available and subsidized by the school, but if they need additional resources, additional computing power, they're able to buy it. They actually purchase nodes that go into the cloud and they own those nodes, but when those notes are idle, other people's work can run on it. So they buy into the cloud.

These folks are not very trusting of central IT organizations. Many of them want to do their own thing. In order to get them to be convinced that they ought to participate, we told them, "You buy equipment and, if it doesn't work out for you, you can take that equipment and put it under the bench in your lab and set it up how you want." That made them more comfortable. But, not a single time has anyone ever actually come back and said they were going to take back the equipment.

In essence, it's building the trust of the researchers or the business clients, if you're in more of a business environment, getting them engaged in their requirements, and making sure it will meet their needs.

Of course, the real value of the cloud for us is handling the burstiness of research. Various organizations have different levels of "burstiness," meaning sometimes a project might suddenly need thousands of hours of CPU time. It might need additional bursts of storage and things like that. So, you need to have a cloud that can adapt to those needs.

This actually worked out well for us. It was cost effective, we got to utilize a whole range of services within the cloud, and that allowed us to move forward.

Gardner: Was there a common-ground effect, where you provided a certain services, saw adoption patterns, and responded to that? Did you see a dance between the consumers and the providers in cloud that may have been different than previous modes of IT?

Athanasoulis: Dance is a great way of describing it, because you take the first step with your partners, the ones who are early adopters and want to try it out, and then they talk to their colleagues and say, "This actually worked out well for us. It was cost-effective, we got to utilize a whole range of services within the cloud, and that allowed us to move forward."

Skilton: It's interesting about the dance, but I think one of the things I am seeing is an incremental revelation, or do you have to have a critical mass? I'm assuming you must have had some kind of critical number of people to cost-justify the boot of the cloud. In the ideal world, the one to many or just starting off with one or two people and growing incrementally, financially that's not usually possible. How did you get around that?

Athanasoulis: We really started out by saying to the senior business leaders within the school -- the deans and the others -- "To keep Harvard Medical School as the number-one preeminent medical school in the country, we're going to have to invest a little money, because these folks out there are not just going to adopt this, if they can't see that there is already some utility to it."

So we started out with a relatively small cloud initially. Once people saw the value, they began to adopt it more, and it's really starting to have a snowball effect, where we are growing by orders of magnitude.

Gardner: Henry?

Peyret: In the bio business, before the cloud was formed, there was grid. Do you think that was key to bring some credibility to your approach, for some researchers and for some business users?

Personal relationship

Athanasoulis: Absolutely. Personal relationship is a part of what it's about. We had to make sure that we weren't seen as just a black box that they had absolutely no control over. That was step number one.

Then we also had to make sure that it was very much of an iterative process. We would start with one folk's needs and then realize there were certain other needs.

Of course, within the biomedical sphere, as I alluded to earlier, there are some unique things. There are certain types of data, protected health information, that you simply have to make sure is protected.

There are things like the Health Insurance Portability and Accountability Act (HIPAA) that requires that health data is protected in certain ways. A lot of extra concerns come into play within the biomedical area.

Gardner: Hearing this sounds as if that iterative approach, the dance effect, is a strong selling point in taking cloud into an organization that's been used to two- to three-year year upgrade cycles, six- to 12-month cycles for the processing of requirements, development, test, deploy, re-requirements, and so forth. Perhaps, cloud allows for agile development and Scrum benefits but for the rest of us?.

It's a subtle difference, but it's one that is fundamentally changing the way you would offer an incrementalized service as opposed to more of a clunky, project-based, traditional waterfall approach.

Athanasoulis: This is true not only in the cloud, but it's true across the whole information technology industry. People are moving from the giant project, two- to three-year implementation cycles to, "Let's take a chunk, see how it works, and then iterate and moderate along the way."

Gardner: Mark Skilton?

Skilton: One of the things we're also seeing is how it affects traditional application development life cycles. What's illustrated here is this need to move to more continuous-release or continuous-improvement type of life cycle. This is a transformation for IT, which may be typically more project-cycle based. It's a subtle difference, but it's one that is fundamentally changing the way you would offer an incrementalized service as opposed to more of a clunky, project-based, traditional waterfall approach.

Gardner: Pam Isom, wouldn't that be appealing to both the IT side of the house as well as the business? Is this that common ground we were looking for, that the iterative constant, more streamlined, but persistent approach is better than the fits and starts, for both sides?

Isom: I would think so, based on the experiences that I have had, I would say yes to that.

Gardner: It probably also allows us to bring in more metrics to measure the benefits. We have, of course, heard of soft, qualitative metrics like agility, but if we have this constant, iterative, step-by-step, crawl-walk-run, we might be able to apply metrics to each of those steps, rather than try to come up with a return on investment for a $40 million project.

Henry, do you have any thoughts about whether the metrics or measurement of success in a cloud-iterative approach will be of more use than some of the past approaches?

Key agility concept

Peyret: I am fundamentally against the fact that agility is a soft metric. I published in 2007 the key agility concept that we should use now. It's something that is quantitative, not qualitative. Believe me, we can define now what agility means at the business and the IT level, and then the cloud and additional technologies, including joint development. But, that's not the same part of agility that I am talking about, which can help to provide some agility as a business.

Even IBM endorsed that one or two years ago for demonstrating SOA and that sort of thing. They collected more than 300 key agility indicators for 22 or 27 types of industries. So, that's interesting.

Just to come back to your point, yes, there are some new metrics, and there would be more and more metrics about that. We talked a lot about the aspect of cost and that sort of thing. There is a big shift after Copenhagen. Most of the enterprises now are endorsing the three bottom line approach. They are reporting not only on the finance aspect, but also on risks. If banks had done that before, we would not be in the subprime problem.

And, the third one, which is about sustainable business. Because of sustainable business requirements, we will measure additional metrics, and the cloud should share additional metrics as well. The more we are involved with some cloud systems in your information systems, the more they should share what type of pollution they are providing and what type of consumption they are doing to include that into the three bottom-line metrics that your CEO would require from you.

Gardner: Let's see how this works in practice. Marcos, did you feel that, on the IT side, you had an easier time validating your efforts, demonstrating the value through some of the cloud activities, as compared to earlier modes of delivery?

Come on and try it out. If it doesn’t work for you, so be it, but you also have demonstrated successes that people can point to.

Athanasoulis: Absolutely. It's always easier to show someone something that's already working and say, "Do you want to hop onto this bus" than to say, "We're going to build this great new giant infrastructure, and just trust us, it's going to work great. So, hop on board now, before anyone has even seen it or tried it out." It's having the ability to let people walk before they run. Come on and try it out. If it doesn’t work for you, so be it, but you also have demonstrated successes that people can point to.

Gardner: I imagine this has to be a two-way street. Where is the point in the middle, between the discussion of value on the business side and the IT side, is that something that the CIO does or the architect? Where did you see, in terms of the politics or the organization? Where was that discussion translated?

Athanasoulis: It's complicated, because the discussion happens everywhere, from in the cafeteria, to meetings with faculty, and in one-on-one communications. Obviously, the CIO is instrumental.

The CIO at Harvard Medical School, John Halamka, had the vision to start this. It started with his initial vision and going to bat to move from everyone from doing their own thing and setting up their own infrastructure, to creating a cloud that will actually work for people.

He had the foresight to say, "Let's try this out." He went to his leadership, the dean and others and said, "Yes, we're taking a chance. We're going to spend some money. We're not going to spend a huge amount of money until we prove the model, but we're going to have to put some money in and see how this works." It was a very interesting communication game.

Gardner: Henry, where does the enterprise architect fit into this dance of value between consumption and provider?

Business service catalog

Peyret: The EA should participate to establish and negotiate what I call the business service catalog, something that will be an extension of the ITIL service catalog, which is very IT-based and IT-defined.

Something that is missing currently within ITIL V3 is how to deal with the business to define the service and define also the contract in terms of cost and of service level agreement (SLA). But, it's not only the SLA. It's broader than that. That's something that's missing at the moment. Most of the EAs are not participating in that.

I have built a sort of maturity model, and I discovered that the EA to deliver a project on time, which is the sort of next point for the EA, should work on the definition of business service catalog.

That's what I wanted to ask to Marcos. Is that something that you're dealing with today, trying, at least at the beginning, to define the service at a business level?

Athanasoulis: Yes. Defining the service with the users is the first clear step, and obviously getting the requirements from the users, particularly in an organization like our medical school, where they have choices and they don’t have to use the systems.

We have people who want to just come in and put in systems, buy a rack of stuff and put it under the lab bench, and then they are surprised when the power and cooling isn’t there to meet the requirement.

Various industries have a different IT maturity level. Unfortunately, Harvard Medical School actually is rather at the bottom of that from a user point of view, because most of the people are trained in life sciences and know absolutely nothing about best practices in IT.

So, we have people who write software, but have never heard of source control. And, we have people who want to just come in and put in systems, buy a rack of stuff and put it under the lab bench, and then they are surprised when the power and cooling isn’t there to meet the requirements.

So, having this balance of bringing in an IT specialist, the enterprise architect, to define the requirements in joint-step -- back to the dance with the customers -- was really what allowed us to be successful.

Gardner: While you're a unique organization, it sounds as if you might be a harbinger for the future. You are talking about a marketplace of services that you allow your users to shop from. That strikes me as something that will be a valuable tool for discerning where the traction is, both in terms of the technology capabilities, but where the human behavioral factors kick in, and even group factors and socialization.

Is that marketplace something that you think will become more the norm, and this is open to our panel? Traditionally, IT has been ... "Here are the marching orders, here are the apps, here are the methods, here is the data, here is the processes, now march." If we give people, vis-à-vis cloud approaches, more choice, wouldn’t that build trust, wouldn't that give us a chance to discern where the real interests are? Let’s hear about a marketplace approach from cloud computing, Mark.

A new question

Skilton: In a nutshell, what we are seeing with clients now is that they are over the initial infrastructure as a service (IaaS), platform as a service (PaaS), SaaS, and business process as a service-sort of conversation. They're now asking, "What cloud services do you do?"

What they mean by that is that they need to see your cloud security reference model. They need to see your cloud services model. They need to understand the type of services that you can offer into a portfolio and then the types of service catalogs that you can interact with them.

They then make a decision. Does that need to be on-premise, can it be out in the cloud, or is there something as a hybrid? They're on that page now, and there is a strategic planning process starting to evolve around that. So, yes, I'd concur that we do need to do that.

Gardner: Pam, what about a market basket of services that constitutes processes that aren’t necessarily locked into processes to begin with, but are delivered to the market to let them exercise the choice?

Isom: Based on what I've seen and experienced with customers, the catalog of services would be great. I think we need to be careful about that catalog of services, so that it doesn’t become too standardized.

We need to be careful with the catalog of services that we offer, but I definitely think that it is a new way of thinking, when it comes to the role and capacity of IT.

As I mentioned earlier today in one of my presentations, you want to be careful with that standardization, because you do want to give people some flexibility, but you need to manage that flexibility. So, you need to be careful. We need to be careful with the catalog of services that we offer, but I definitely think that it is a new way of thinking, when it comes to the role and capacity of IT.

It’s a new way of thinking, because along with that comes service management. You can't just think about offering the services. Can you really back up what you offer? So, it does introduce more thinking along those lines.

I want to go back to your question earlier about the iterative approach, and then you asked about the enterprise architect. If we tie those two together, the enterprise architect would be the one who would provide that enterprise view and make sure that anything that we do is thought out from a holistic perspective, even though we may actually start practicing on a smaller scale or for a smaller domain.

A good practice would be to involve the enterprise architect, even though we may start with a specific domain for implementing the cloud, because you've got to keep your eye on the strategic vision of the company.

Gardner: Henry, we started talking about cloud, but then we got into service catalogs. It almost sounds like the service oriented architecture (SOA) route. How do those come together in your thinking?

Peyret: The business service catalog is the next step. We have heard in enterprise architecture about business capabilities. We talked about that business capabilities to help develop business architecture.

A missing link

We have also heard SOA. There is a missing link in between -- the business service catalog. It's a way we will contractualize. I like very much the fact that you said, we are contractualizing, but with flexibility. We should manage that flexibility. We should predict what that flexibility means in terms of impact. Perhaps that service is not valuable for other parts of the company.

That's where I think that EA and the next step for EA will take place. SOA is not an end, and the next step will be the business service catalog, which we will develop to link to the business capabilities.

Gardner: Mark Skilton?

Skilton: I concur with that, and I am also detecting at this conference and some of the work we're doing in The Open Group that there are worries around the risks of achieving the catalog flexibility. I agree. You're absolutely right. The portfolio needs to be put in place, but it also needs another set of service management investment tools to control data distribution, compliance, or access and security control, and things like that.

I detect a worry about whether I can outsource that. Do I need to do something in-house? What do I need to spend money on? Because that's a block, and people need to understand that.

Gardner: Let's go to our harbinger of the future, the Harvard Medical School here in Boston. What did you do to prevent the rewards from outstripping the risk, that is to say spinning out of control?

You don't want to sell something to everyone and then find six months into it that you're way oversubscribed and everyone is bitter and unhappy, because there isn't the capability that they expected.

Athanasoulis: Again, starting small. To build on what my colleague was saying, you want to iterate and you have to have a vision of where you are going.

If you're taking a car trip and you're going to drive from here to Ohio tomorrow, we know where we're going, we have our map, we start to drive, but we might along the way find, that the highway is clogged with traffic. So, we're going to go around over here, or we are going to take a detour.

Perhaps, somewhere along the way you say, "You know what, now that we have been learning more, Ohio isn't really where we wanted to go. We actually want to keep on going. We're heading right out to Colorado, wherever it may be." But, you have to have a vision of where you are going.

Then, to keep things from spinning out of control along the way, it's really important to know the potential factors that might lead to things starting to fall apart or fray at the edges. How do you monitor that you have the right capacity in place? You don't want to sell something to everyone and then find six months into it that you're way oversubscribed and everyone is bitter and unhappy, because there isn't the capability that they expected.

You have to also make sure to check in with folks along the way a lot. Part of my MO of dealing with a wide set of customers is constant contact with them. I'm always checking in because, as IT leaders, we know that you don't usually hear when things are going well. You usually only hear when things are going poorly. And, even then, you don't always hear when things are going poorly. You have to make sure to get that feedback, because people will just drop off and go find some other way to get done what they need to get done.

Gardner: To continue with our dance metaphor, you don't just drop them off at the dance. You have to stay with them.

Athanasoulis: That's right.

Gardner: Let's look a little bit at the public and private divide issue. We have heard public cloud, private cloud. What do you use, and do you make a distinction around public and private cloud?

Now a marketplace

Athanasoulis: I think it makes clear sense. To some degree, as IT leaders, we all know that there is now a marketplace. The public cloud is available to folks. People can get on Amazon EC2. They can get on to these various clouds and they can start to use them. That forces us to have compelling cloud offerings that are more cost effective than what they can go get out in the public sector.

For us, when you set aside the issues of protected health information and HIPAA and other things like that, there’s plenty of research and business processes that don’t have those security concerns. We view the public cloud as an extension of the private cloud to the degree that there is consistency of virtual machine definitions and to the degree that we can make a node on the public cloud look exactly like a node on the private cloud and make the same databases available there.

If someone has the money, they want the capabilities, say 10,000 processor hours or 100,000 processor hours, whatever it might be, between now and this deadline three weeks from now, and they are willing to spend the money, wouldn’t it be great if transparent to them, they just spend up to $100,000, $200,000, whatever their budget is, and let this stuff go from our private cloud out to the public cloud. What a great solution that would be for folks.

Gardner: Mark Skilton, is it the role of the enterprise architect to be the arbiter of public and private? It sounds like in Marcos’s case there is a bit of self-selection and being driven by the users. I think that’s a bit unique to that type of organization. Isn’t there going to be a traffic cop of some sort to then allow for these services to be used, but with the acceptable level of risk, and so doesn’t the role of IT shift from providing IT to brokering IT services?

Skilton: It’s a funny dimension I have come across, where you have the purchasing or the procurement department having procurements and license strategies and license agreements that could be within a particular business or across a number of businesses, and it could be related to a country or a company or a collection of companies or countries.

It’s not the role of the EA to make the choice. That’s the role of IT, responsible to the CIO.

It was an interesting point Marcos made earlier about needing not only a vision, but articulating the vision as a roadmap. What I think you're inferring is almost like a technology and purchasing roadmap.

I often ask how often an enterprise architect bothers to find out what’s in the data center, when they go ahead and do development? There's probably a new style of communication, that maybe not the enterprise architect, but the architecture department, the AMO or the PMO, start to put out a service briefing about what they can do.

Just a very quick story. In Australia, a couple of years ago, I was over in BHP Billiton, a major, massive mining operation. I always remember the CTO there looking me in the eye and saying, "Do we need requirements from users, because all I have to do is put out a catalog and make them buy off that?" He was being candid with the whole process. Perhaps we are not there yet, but instead of this mentality of design to order, we need to move more to assemble to order, or made to stock.

Peyret: Can I answer your first question? I would be provocative about that. For me, it’s not the role of the EA to make the choice. That’s the role of IT, responsible to the CIO, to say yes or no, I would like to deliver that service internally or not internally, that’s part of my service delivery. If you want to be seen as a service delivery within your company, you should act as a business person saying, "Yes, I want to keep that service internally or I want that service to be delivered externally."

Final decision

Yes, the EA can help. Yes, the EA can participate through the gateway that I talked about previously. Yes, the EA can be instrumental to know if it makes sense to have that service at that point and that sort of thing. But, the final decision is not in the EA space.

Gardner: Okay. Coming back full circle to our goal here of uncovering ways to better take, sell, or bring cloud computing to the business side of the house. ... We have talked about that role of broker that Marcos and Mark discussed a bit: procurement, contracts, agreements. These are terms that the business side understands, more so than enterprise service bus (ESB), Agile, and Scrum. Is there a commonality there, where IT becomes something as a business function that the business leaders, those with the purse strings, can better understand?

Isom: Just from my experiences and customer interactions, the IT department should be more focused now on providing information technology as a service. It’s not just a cloud figure of speech. They are truly looking at providing their capabilities as a service and looking at it from an end-to-end perspective.

That includes that service catalog and includes some of the things you were talking about, how to make it easier for consumers to actually consume the services, and also making sure that the services that they do provide will perform, knowing that the business consumers will go somewhere else if we don't. The services are just that available now. You really have to think about that. That shouldn’t be the driving force for us, providing IT as a service, but it should be a consideration.

The IT department should be more focused now on providing information technology as a service. It’s not just a cloud figure of speech.

Gardner: Let’s do a quick series of recommendations from each of our panelists. We'll start with you, Henry. One major recommendation you would make to the IT organization and the enterprise architects about convincing the others in the organization that cloud is a good thing.

Peyret: That’s not exactly the question I wanted to answer, but let me rephrase a little bit in my mind.

Gardner: Give it your best shot.

Peyret: What I wanted to recommend is that you should evangelize your IT person to act as an IT service. What does that mean? That means that you should recommend to them to contractualize their service, to express and establish, through the business service catalog, including some pricing aspects. Within the enterprise, where you have some funding and no problem about funding, you should contractualize. That’s absolutely key to make the adoption of cloud, any type of cloud, easier. That would be more or less transparent.

Gardner: Pam, I am going to rephrase the question. What are some recommendations you can make that both the IT and the business side of the house could agree on, when it comes to either cloud or the effects the cloud provokes in the organization?

Risk mitigation

Isom: I was having a conversation with someone earlier and we were talking about the fact that cloud can be a risk mitigator, and we're going to have some follow on conversation about that. If I think about how cloud can be a mitigator of some risk, I'll just name some of the risk that we discussed. We talked about how we can help mitigate the risk of losses in product, sales and services, because capabilities are now made faster. There is also that infrastructure to try things out. If you don’t like it, try something else, but that infrastructure is more readily adaptable with cloud.

Also, there's the fact that there is the mitigation of the proliferation of licenses and excess inventory that you have with respect to products, software, and things like that. We can help mitigate that with the cloud, with the pooling of licensing and things like that, so you can reach cloud from that respect.

Our discussion was around how to see cloud as a risk mitigator. I won't go into them all, but those are two examples.

Gardner: Great. Mark, same question.

Skilton: There is one lesson for the business side and one lesson for IT. From the business side, I would recommend to go out and look at best practices. Go and look at examples of where SaaS is already being used.

The number of case studies are growing by the month. So, for businesses, go out and learn about what's out there, because it is real. It’s not a cloud.

It constantly amazes me how many blue-chip Fortune 500 companies are already doing this.

From an IT point of view, as we have heard from Marcos, go and learn. Try it, pilot it in your organization. I'll go further and say, practice what you preach. Test it out on one of your own business processes.

From my own experience in my own company, we do use what we preach in the cloud. That way, you learn what it means internally to yourself to transform, and you can take that learning and build on it. You can't get it in a book. You can’t just read it. You have to do it. Those are the two key things.

Gardner: Last words, you Marcos.

Athanasoulis: I will think of four words that begin with P to describe where I would emphasize. One, pilot, as we have already been saying. Two, participation. You have to get buy-in and participation across the entire group. Three, obviously produce results. If you don’t produce results, then it’s not going anywhere. And then, promotion. At the end of the day, you also have to be out there promoting this service, being an advocate and an evangelist for it, and then, once the snowball gets going, there is no stopping it.

Gardner: Well, very good. We've been discussing the practical implications of cloud computing models, of moving beyond the hype and into business paybacks from cloud adoption.

This sponsored podcast discussion is coming to you from The Open Group Conference in Boston. We're here the week of July 19, 2010.

I'd like to thank our panelists: Pam Isom, Senior Certified, Executive IT Architect at IBM; Mark Skilton, Global Director of Applications Outsourcing for Capgemini; Dr. Marcos Athanasoulis, Director of Research Information Technology for the Harvard Medical School, and Henry Peyret, Principal Analyst, Forrester Research.

I'm Dana Gardner, Principal Analyst at Interarbor Solutions. You've been listening to a sponsored BriefingsDirect podcast. Thanks for joining, and come back next time.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: The Open Group.

Transcript of a sponsored podcast discussion from The Open Group's Boston Cloud Practitioners Conference on gaining business paybacks from cloud computing. Copyright Interarbor Solutions, LLC, 2005-2010. All rights reserved.

You may also be interested in:

• Enterprise Architects Increasingly Join in Common Defense Against Cyper Security Threats
  

• Business Trends in Global IT Markets Provide New Traction and Value for Enterprise Architecture
  
  
• The State of Enterprise Architecture: Vast Promise or Lost Opportunity?

FACE Initiative Takes Aim at Improved Interoperability and Standards Among Future Military Avionics Platforms

Transcript of a sponsored podcast discussion on the US military's work with The Open Group to develop a computing environment that will smooth cost and schedule issues for new systems.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: The Open Group.

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, coming to you from The Open Group Conference last week in Boston.

We've assembled a panel to explore a new military aircraft systems interoperability consortium and effort, the Future Airborne Capability Environment (FACE), which aims to promote and better support interoperability and standardization among future military avionics platforms across several branches of the U.S. Armed Forces.

We will define FACE, how it came about, and examine the consortium's basic goals under the tutelage of The Open Group.

Here to help better understand the promise and potential for FACE to improve costs, spur upgrades, flexibility, and accelerate the components' development agility is our panel. We are here with David Lounsbury, Vice President for Collaboration Services at The Open Group. Welcome.

David Lounsbury: Hi, Dana. How are you?

Gardner: I'm great. We're also here with Mike Williamson, Deputy Program Manager for Mission Systems with the Navy's Air Combat Electronics Program Office. Welcome to the show.

Mike Williamson: Dana, thanks, it’s good to be here.

Gardner: Mike, tell us a little bit about what FACE is, and the history that led up to it?

Williamson: Sometimes it’s easier to describe a program by saying what it’s not. FACE is not a program. FACE is not a computer. FACE is not a software package. FACE is an environment, and it’s specifically set up as an environment. It was an idea that came about to try to reduce costs, improve interoperability across naval aircraft, and to get capabilities out to the fleet faster and quicker, as best we can.

FACE started out as a Navy program. As we started looking around to see what other services were doing, we found that the Army and the Air Force were also doing similar things and trying to go down that same path.

The Army had a program called Integrated Data Modem (IDM). The Air Force was doing a program called Universal Network Interface (UNI). We got together with them and are now teaming up to put this consortium together and go forward to define standards for what FACE will be.

Gardner: In general terms, what are the problems that we need to solve here?

Cost and schedule

Williamson: The primary problems are cost and schedule. The costs of getting systems to the fleet today are going up. Primarily, it's driven by testing and by the fact that the systems that we have on aircraft today are not open.

As for schedule, it takes a minimum of two years, once a new capability is defined, to get it fielded on our aircraft today. We need to reduce that timeline.

Gardner: For the benefit of our listeners, we're talking about the avionic systems. Can you tell us a little bit more about the actual systems and some of the capabilities that we're addressing with this program?

Williamson: We're really addressing all of the capabilities and all of the systems onboard the aircraft. In the past, we identified a requirement and usually developed a system to meet that requirement.

What we are trying to do with FACE now is to develop a computer environment that’s on the aircraft already. As we define new capabilities and new things that we want to put out into the fleet, we can host software in the computer environment that’s already there, rather than building a brand new box, software, or program for every single capability that we put out there.

Gardner: Dave, I think The Open Group has seen this issue before, right?

Lounsbury: Yeah. It’s very interesting. We've got a number of activities that are on this government-industry boundary, where some of the lessons that industry learned about how open standards can bring agility and help control your cost can benefit military systems like this.

I want to pick up on a thread that you mentioned about schedule, because there’s two sides to that coin. The testing and deployment schedule is a real issue for agility for our forces. The one thing we know is that threats change all of the time, and we need the ability to field new capabilities quickly, both as the mission changes and also as the technology evolves.

We really need that modularity within the necessary structures of testing for things that are going to be used, and be able to get those new capabilities in the cycle quickly and get them out to the war fighters.

Gardner: So how did The Open Group become involved, and what do you expect to be doing vis-à-vis the FACE effort?

Similar areas

Lounsbury: The Open Group has a couple of areas similar to this. We've got our Real-time and Embedded Systems Forum for some of the fundamental standards.

We've been running a consortium called DirectNet, which is very similar to FACE in the sense that it is principally focused on a defense need, but in the context of open systems. Through connections developed there, Mike found us and we talked about what we can do to organize.

Typically, what The Open Group does is provide a structure. Members come in, they bring their business expertise, their subject matter expertise, and operate. What we provide is the framework, where we can have an open consortium that has a balance of interest between the suppliers of components, all government agency programs doing procurement, and the integrators who put it all together. We've got the proven process at The Open Group to make sure that we have that openness that's important for protecting all of the parties.

Gardner: Mike, tell me about milestones and timelines? How far into this effort are we, and what might the fruits of this labor be over time?

Williamson: This idea really started about a year ago in the Navy, within PMA-209, the program office that I represent here, the Combat Electronics Program Office, at the Naval Air Systems Command. We started looking at what we could do and what we needed to do.

What we're going to be doing principally is marshaling, as always, the expertise of the members to address various parts of the problem.

The timeline is very, very tight. We're looking at having some kind of standards defined by first quarter of calendar year 2011 -- next year. By the end of March, we're looking to have defined a set of standards on what the FACE environment will look like, because we have procurements coming out at that time that we intend to have FACE be part of those requests for proposals (RFPs) that are going to be coming out.

Gardner: And for you, Dave, at The Open Group, what do you see as some of the existing efforts that have taken place that you could look to for some guidance? Are there processes, standards, or technologies that will already be available for FACE?

Lounsbury: It's very early, and we're just starting to learn the technical requirements. There are a few that we know that we are going to need. We've talked about the need for operating system kernels that keep the various levels of information to various levels of sensitivity separate. And, there's an active program in our Real-time and Embedded Systems Forum called MILS that's addressing that. I think there will be many that we will discover going forward.

There is also a good background. The Open Group has worked with some other government activities -- the Modular Open Systems Architecture folk. We've got quite a reservoir of expertise there. What we're going to be doing principally is marshaling, as always, the expertise of the members to address various parts of the problem.

Gardner: Let's look to some commonality, Mike, between the commercial world and the efforts for your avionics platforms, this notion of modular and the right balance between components, silos, and an overarching system. Tell us where you expect this to go, not only in terms of your agility, but into better architecture.

Getting beyond

Williamson: One of the things that we have looked at is the fact that commercial industry is doing this. Commercial aviation is already doing a lot of this. We've not been able to do that within naval aviation to date, and primarily that's been driven by safety-of-flight issues, issues within our operability, and issues with how we contract for things. We need to get beyond that.

We're actually using the model of what commercial aviation has done, with open systems, open source software, licensed software, and those kinds of things, to ask how we can bring that into our platforms. We need to have an environment that we can have a library of software applications that can be used across multiple platforms in the same environment.

That solves two problems for us. One, it gets capabilities to the fleet cheaper and faster. And two, it solves the interoperability issues that we have today, where even sometimes when we have the same standards, two different platforms implement the same standards in two different ways and they can't talk to each other. They are not interoperable. Those are the things that we are trying to solve with this.

Lounsbury: I want to pick up on something you mentioned there about following the commercial world, and you articulated a few business drivers in there, like cost, time to market, and things like that. One of the explicit goals of FACE, and we performed a business work group to address these, is to talk about the business-model issues. What does open licensing mean in a government context? What would be appropriate ways of sharing intellectual property rights (IPR) in the run up to this?

These are all things that commercial people are familiar with through years of standards activity, but it's kind of new to some of the players in the government space. So, we're going to make sure that those things are explicitly addressed. It’s not just the technological solution, though that’s the critical part, but the fact that people can actually buy -- and that we will have a marketplace of -- components that can be licensed and reused.

The government is a complex place, and there are lot of programs, so principal growth will be different programs inside the government. But, we do envision that some of the things that will be developed here may be applicable to other systems.

It's early on how we are going to do that, but it’s a very active topic inside the consortium.

Gardner: Do you see an extensibility that this effort with FACE might have some bearing on where you could go in other areas of either the military or government?

Lounsbury: Certainly. Obviously, we started FACE. The Navy came to The Open Group, but once the word got out, the Army and Air Force are on board. So, we've started to branch out into agencies.

The government is a complex place, and there are lot of programs, so principal growth will be different programs inside the government. But, we do envision that some of the things that will be developed here may be applicable to other systems. Part of the vision is, in fact, how does this start to overlap with the commercial avionics practice that Mike mentioned earlier.

Gardner: And, we've got our timeline. We understand that there are going to be some improvements pretty rapidly. Is there anything about the standardization process, Mike, that is perhaps different than you expected? Is there any learning process so far?

Williamson: There have been a lot of things that I've learned, having The Open Group come along and take a lead on all of this and developing the standards. The Navy and the Department of Defense (DoD) aren't real good at developing standards ourselves. We've tried to do it in the past and we've failed miserably with some of the attempts that we have had. Having The Open Group come and join us, and then bringing industry in, was the right thing to do.

Having this consortium with industry, Navy, Army, and Air Force acquisition teams, and fleet participation, has been the right way to go. It’s the only way we can really define the standards and get in place the standards that we really need to get at, with all those inputs coming together.

Gardner: We've been discussing a new military aircraft systems interoperability effort and consortium, the Future Airborne Capability Environment or FACE effort, and how it promises to improve costs, spur upgrades, flexibility, and accelerate avionics components' development agility.

I'd like to thank our guests. We've been joined by David Lounsbury, Vice President of Collaboration Services at The Open Group. Thanks, Dave.

Lounsbury: Thank you, Dana.

Gardner: And, we've been joined by Mike Williamson, Deputy Program Manager for Mission Systems, with the Navy’s Air Combat Electronics Program Office. Thank you.

Williamson: Thank you, Dana.

Gardner: This sponsored podcast discussion is coming to you from The Open Group Conference in Boston the week of July 19, 2010.

This is Dana Gardner, Principal Analyst at Interarbor Solutions. You've been listening to a sponsored BriefingsDirect podcast. Thanks for joining, and come back next time.

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Download the transcript. Sponsor: The Open Group.

Transcript of a sponsored podcast discussion on the US military's work with The Open Group to develop a computing environment that will smooth cost and schedule issues for new systems. Copyright Interarbor Solutions, LLC, 2005-2010. All rights reserved.

You may also be interested in:

• Enterprise Architects Increasingly Join in Common Defense Against Cyber Security Threats
  

• Three new Open Group white papers help make for a peaceful leap to cloud computing
  
  
• The State of Enterprise Architecture: Vast Promise or Lost Opportunity?

• Business trends in global IT markets provide new traction and value for enterprise architecture