Transcript of a sponsored podcast discussion on turning cloud computing into business paybacks.

1. Exploring the Business Decision to Use Cloud Computing
Transcript of a sponsored podcast discussion on turning cloud computing into business
paybacks.
Listen to the podcast. Find it on iTunes/iPod and Podcast.com. 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’s Security
Practitioners 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 issues, such 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.
Please join me in welcoming 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.

2. 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 process
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
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 to
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
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.

3. 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 when the competitors are
going down 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 on 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?

4. 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 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.

5. 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.

6. 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 2-3 year upgrade cycles, 6-12
month cycles for the process of requirements, development, test, deploy, re-requirements, and so
forth. Perhaps, cloud allows for the agile development and Scrum benefits for the rest of us.
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.

7. 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?
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.

8. Gardner: Henry, where does the enterprise architect fit into this dance of value between
consumption and providing?
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.
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
requirement.
So, having this balance of bringing 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 allows 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.

9. Is that marketplace something that you think will become more the norm, and this is open to our
panel? Traditionally, IT has been, here is 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 (BPaaS) 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 into 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 talks 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.
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.

10. 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 term 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?
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

11. 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.

12. 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’ 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 service?
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 was an interesting point you 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."

13. 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.
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?

14. 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 practice. Go and look at examples of where SaaS is
already being used.
It constantly amazes me how many blue-chip Fortune 500 companies are already doing this. 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.
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.

15. 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’s Cloud Computing
Conference in Boston. We're here the week of July 19, 2010.
I'd like to thank our panelists. We've been joined by Pam Isom, Senior Certified, Executive IT
Architect at IBM. Thank you. Also, 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. Sponsor: The Open Group
Transcript of a sponsored podcast discussion on turning cloud computing into business
paybacks. 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?