Interoperability in the cloudUnderstanding the challenges of integrating cloud in your organisation

IntroductionCloud computing is now at the point where it can no longer be considered as just hype. Although it varies by industry sector, many organisations are now either implementing or planning to implement externally-hosted cloud solutions. However, in all cases that PA Consulting Group (PA) has come across no organisation is yet moving all of their IT services over to a single vendor cloud offering and so will have to work within a ‘Hybrid cloud’ IT environment.

The majority of organisations who choose to utilise

cloud services over the next couple of years will be

doing so through a mixture of:

• Cloud services procured from multiple vendors

• Cloud services and their own traditionally-

hosted systems.

Therefore, these organisations will have to face the

challenge of ensuring that the individual services

within their portfolio of IT services can interoperate

successfully with each other.

This white paper reviews some of the interoperability

challenges associated with cloud computing based on

interviews with early adopters within the pharmaceutical

sector1, examines the positioning of some larger service

providers in relation to these issues, and finally

discusses ways in which organisations might address

potential interworking issues.

The paper focuses on interworking with cloud services

and uses in the pharmaceutical sector as a source of

experience because:

• by comparison to other issues, interoperability is not an

area which has so far received much attention and PA’s

clients are now starting to encounter issues in this area

• when considering large enterprises the

pharmaceutical sector appears to be at the leading

edge of being prepared to shift to externally hosted

cloud services eg, GSK is an early adopter of

Microsoft’s Business Productivity Online Suite (BPOS)

that provides cloud email and collaboration services.

Private cloud services – those existing completely within

the boundary of the enterprise – will not be considered

as part of this paper, as they are subject to far greater

corporate control and hence issues arising from them

are likely to be significantly different to those arising

from the use of public cloud services.

1 Chosen as a sector more likely to adopt cloud services because innovation is so central, particularly to pharmaceutical R&D

What is a cloud service and what are the most common concerns?Establishing a baseline for the cloud

The term ‘cloud service’ can potentially be attached

to a wide range of different commoditised services

delivered over the Internet or a corporate Wide Area

Network; from the shared metered access to raw

infrastructure to high value-add managed services

involving people as well as computers. However, cloud

is most generally associated with the range of services

highlighted in red in Figure 1, from flexible modular

“on-demand” computing blocks through to high value-

add software applications as a service (SaaS). The

common concerns about the cloud outlined in this

section – and which are never entirely separable from

issues of interworking – cover all the components

of cloud delivery from raw storage and processing

through to SaaS. Interworking, in contrast, is particularly

concentrated on the SaaS component and a security

element not shown in the diagram: access control.

Positioning of two major cloud service providers as

an illustration of cloud complexities

Figure 1 represents only one dimension based around

raw technology of how cloud services can vary from

one provider to another. Interoperability in particular

requires an understanding of ‘softer’ issues around how

two services at a given level can interwork at most basic

level ‘satisfactorily’ and, ideally, at a more advanced

level ‘seamlessly’ (see Figure 2). But even softer are

the people factors around how people would like to

work, and what makes them more motivated and

hence more effective: issues of cultural match between

‘productivity software’ and those it is supposed to make

more productive.

To illustrate these issues, this section examines two

major cloud players, Google and Microsoft, who are

both targeting the delivery of core services from very

different perspectives:

• Google promotes a very different way of working

based around increased collaboration and sharing of

information. Its model aims to revolutionise the way

organisations do business, by adopting a solution

which intuitively links together modern workday

activities, sitting alongside the likes of Facebook.

To be effective in the enterprise environment, this

new model needs to interoperate with the existing

workflows embedded into legacy systems.

• Microsoft is promoting more ‘business-as-usual’

solutions in the cloud but with enhancements which

they believe match, or come close, to what Google

and others are offering in the same space. In order

to ‘cover all bases’, it is offering a range of different

service delivery solutions to address what it sees

as different demand profiles. Its key differentiator,

Figure 1: Potential scope of ‘cloud services’ (the most common view of what cloud is, is outlined in red)

Human skills

Services ecosystem

Business processes

Business value-add

Applications

Appliances/value-enhanced infrastructure

Infrastructure

Supporting resources

Modular computing blocks

Example: Consultants, crowd-sourcingProviders: Advisory companies, ordinary individuals

Example: Call centre servicesProviders: Third party service providers

Example: HR, payroll, billing, invoicingProviders: Third party service providers

Example: Business intelligence, salesforce.com (eg high value-add)Providers: Third party service providers

Example: Gmail, collaborative working, etcProviders: Third party service providers

Example: Amazon VMs, web services (eg low value-add), enhanced de-dupe storage servicesProviders: Data centre hosting providers

Example: HP Cells, Cisco Vblocks, etcProviders: Data centre providers

Example: Network services, telephonyProviders: Data centre and network providers

Example: Data centre spaceProviders: Data centre and network providers

Peo

ple

App

s (S

aaS

)P

roce

ssin

g/st

orag

eIn

fras

truc

ture

2

however, is a relatively painless transition to a hosted

environment through tight integration of services

such as Active Directory and similar core products

(for example, office automation) to those already

in use within the company.

Inevitably, the Google approach induces a certain

amount of corporate and ICT pain. Individuals have to

learn new ways of working and, although these are seen

as beneficial in the longer-term, there is nevertheless a

change process to be gone through. On the ICT front,

Google presents several challenges in terms of service

integration – linking back into legacy applications –

and in terms of authentication and authorisation.

Microsoft, on the other hand, plays to the corporate

ICT department, soothing concerns about disruption

to existing services and promising a more gradual

transition to what it proposes is little dissimilar to

Google’s offering. Anecdotal evidence suggests that

the Microsoft’s services are similar to Google’s with

the added advantage of tighter integration with existing

solutions such as Microsoft Office. They are also being

demonstrably more open than they have been in the

past, sharing their standards and specifications and

accepting the important of interoperability. For example,

The Microsoft Azure applications hosting platform will

allow you to run applications developed on non MS tools

such as Ruby on Rails.

Of course, as Apple has demonstrated with the iPhone

and doubtless will also demonstrate with the iPad, being

radical and doing things differently is a major attraction,

even within relatively conservative large enterprises.

This really points at a major difference between the

two offerings, who nevertheless claim to be offering

much the same outcome: appealing to people for whom

radical change is an expression of freedom, where

the naturalness of the Google paradigm and Google

image as ‘cool’ delivers a sense of empowerment,

versus appealing to people in cultures where continuous

improvement through controlled product evolution is the

accepted norm. Both alternatives are equally valid.

So the choice of cloud services is as much about culture

and image as it is about more down-to-earth issues

about how to make it work. But that should not be taken

to mean that choosing a ‘cool’ solution automatically

changes corporate culture or improves productivity

through better or more natural ways of working. Culture

is complex and the desire to stick with existing ways of

working can extend well beyond ICT departments deep

into the organisation itself.

Another option, particularly in a multi-cultural organisation

is to consider technological diversity with more than one

type of core ICT environment supporting the different

cultures of different groups of workers. This really does

require tackling the interworking challenge head on,

which forms the basis of discussion in the remainder

of this paper: how to work collaboratively and share

information painlessly in a diversified ICT environment.

Even with mixed desktop economies of PCs and

Macintoshes it is possible to share documents and email

through the common use of Microsoft Office or Open

Office, but combining Google and Microsoft solutions

potentially requires more compromise and adaptation.

Interoperability challenges are always going to exist

between different cloud platforms, however owing to the

‘core’ functionality provided by Google and Microsoft the

issues are more visible to end users.

Interoperability challenges are always going to exist

between different cloud platforms, however owing to

the ‘core’ functionality provided by Google and

Microsoft the issues are more visible to end users.

Figure 2: Levels of interoperability

Interfaces and process are defined across boundaries albeit with manual intervention

Interfaces and processes are invoked automatically, compromises exist but are identified

Information shared and functionality invoke across multiple platforms, but boundaries are visible to users

Information shared and functionality invoked across multiple platforms transparently and unperceived by users

Level 1: Satisfactory

Level 2: Developed

Level 3: Advanced

Level 4: Seamless

3

Figure 3: Key challenges and considerations for cloud

Security How is data protected, where is it located, how can it be made to conform

with national/European laws on privacy etc?

Who else may be involved in manipulating my data? eg cloud providers

to cloud providers.

What if a cloud provider changes ownership eg to a competitor?

Service continuity How much risk is created by the increased dependency on external

communications links?

How is customer data protected from loss? What happens if the cloud

provider loses customer’s data?

What data recovery requirements are there for cloud services? eg how much data

can an organisation afford to lose while still remaining functional

Migrating into

the cloud

What is involved in moving to the cloud?

What ‘ways of working’ do you have to change to accommodate a change to the cloud?

Operating in and

with the cloud

Will the functionality provided by potential cloud offerings meet the business need?

Does the cloud deliver appropriate performance (bandwidth, latency, etc)?

Is it possible to exchange data between the cloud and ‘legacy’ corporate environment

with no loss of content or formatting?

Is it possible to invoke functionality in both directions ie, from the corporate environment

into the cloud and vice versa?

Is it possible to exchange data and invoke functionality between the individual cloud

services used by a customer?

Is it possible to deliver a common authentication mechanism across cloud and

corporate services, including directly between cloud services?

How will cloud services evolve? Will they be innovative? What are the

supplier’s key drivers?

How well do the supplier’s drivers correspond to customers’ own expectations

of how they want their business to evolve?

How can the evolution of services provided through integrating offerings from several

SaaS providers be managed over time? risk of divergence?

Customer service What level of customer service will be offered by the cloud provider? Will it correspond

to customer expectations?

Is there any opportunity to tailor customer service to particular customer requirements

eg, differentiation for different groups of people?

Getting out

of the cloud

What are the implications of moving a service or data out of a cloud service, whether back

in-house or to another cloud provider?

Overriding concerns Can customers trust a cloud provider to be around for the long-term?

Can customers trust a cloud provider to look after their data and be

responsive to their evolving requirements?

How should/can customers compare existing costs versus cloud costs, both now and in

the longer term? Trust a cloud provider to look after their data and be responsive to their

evolving requirements?

Will the current cost equation of ‘processing expensive, communications cheap’

which is driving the cloud, survive?

4

What are the most important concerns affecting interoperability?Figure 3 summarises some key challenges and

considerations for cloud, which we have gathered

from a variety of PA clients. We have highlighted

in red those issues we feel to be specific related to

interworking/interoperability.

The ability of cloud functionality to meet business need

is often considered in isolation, almost on a feature-

by-feature basis. This can easily miss a key element

of business need: that in most instances a significant

element of the overall business need will continue to

be served from existing ICT solutions which, for the

purposes of simplicity, we refer to in this paper as

‘legacy’. And unless functionality is neatly partitioned

within a business, interworking immediately becomes

an issue – how will information received from, or sent

to, a cloud service be integrated with the remaining

legacy applications?

So selecting which parts of ICT delivery can be

outsourced to the cloud should ideally take account of

how easy it will be to integrate any cloud services with

the legacy environment. As with any major paradigm

shift in ICT, the easiest areas to outsource to the cloud

are those which sit on the periphery of the legacy

environment, those which are most separable and have

the least ‘connectors’ into that environment – connectors

which may have to be extended into the cloud to

maintain continuity of business service (see Figure 4).

This view is reinforced by interviews with

pharmaceutical companies where the greatest interest

in moving into the cloud seems to be around relatively

stand alone applications with few interconnections

with the rest of the ICT estate. Highly connected core

services with significant levels of interaction between

legacy ICT systems are generally not yet being

considered as suitable for moving into the cloud.

Figure 4: Core services are generally more heavily linked with legacy systems rather than those at the periphery

Corporate ICT

Peripheral service

Core service

Cloud supplier A

Cloud supplier B

5

Access control

Legacy environment

Direct functional invocation/receipt

Embedded functional invocation

Metadata

Raw data

Access control

Cloud

Direct functional invocation/receipt

Embedded functional invocation

Metadata

Raw data

Cloud

Documents,spreadsheets,

etc

Information interchange

Is it possible to exchange data between the cloud and

‘legacy’ corporate environment with no loss of content

or formatting?

This question is posed as an extreme ideal (see Figure

5): that it should be possible to pass information back and

forth between different environments, using potentially

different tools (eg spreadsheets) to manipulate the

information without any corruption of the information and

any associated meta-data (eg formatting information,

mark-up history). But is it achievable?

Certain areas of information-sharing technology have

managed to achieve this level of compatibility most

notably for Internet email through the use of standards

such as SMTP and MIME. But pure email is a relatively

simple application. E-mail enhancements such as

real-time meetings schedulers offered in corporate

applications are not standardised, even if there are

common formats for sending meeting requests

(this is discussed further in the next section).

Similarly, word processing, spreadsheet and database

applications, to pick but a few examples, do not use

standard formats for the data they manipulate. Each

application has its own key capabilities associated

with which it needs to store meta-data alongside

the raw data. XML provides one way of structuring

data and metadata such that it can achieve greater

application independence but even then, this cannot

guarantee absolute independence eg, for spreadsheets,

where data, metadata and also embedded functional

invocation are so closely interdependent.

So what does this mean for organisations interworking

with the cloud? Data conversion issues are likely to arise

in mixed application environments where structured

information is being passed between one environment

and another, such as between cloud-based applications

and traditional corporate applications. For example,

a cloud-based spreadsheet application is unlikely to

support the capabilities offered by Microsoft Excel so

passing a spreadsheet between the two is likely to lead

to loss or corruption of information or functionality.

As mentioned earlier, this incompatibility is more likely to

be an issue with core applications moving into the cloud

as they typically have very rich and deep interconnections

with other applications which will need to be maintained.

Organisations need to understand the extent and establish

if any data lost (or corrupted) when interoperating

between platforms is detrimental to the business.

Looking back at the earlier discussion about cloud

suppliers, it is clear that Microsoft is following the

lower-risk route in terms of maintaining existing

capabilities across the interworking levels.

Is it possible to invoke functionality in both directions

eg from the corporate environment into the cloud and

vice versa?

The next level up from information compatibility is the

creation of functionality across interfaces with cloud

services and associated capabilities and flexibility. Any

higher-level cloud service will, de facto, offer a capability

to interact with it to pass information in and extract results.

Figure 5: Working with the cloud requires multiple levels of compatibility

6

Functional control should not necessarily be seen as

purely one-way. A SaaS environment may also need

to request an action of the corporate environment such

as, for example, calendar synchronisation. Application

Programming Interfaces (APIs), such as those offered

by Google, are tending to follow a web services model

using REST or SOAP and XML-formatted messages

transferred directly across an IP infrastructure.

The real issue, therefore, is how effectively the

interface supports the capabilities required by the

corporate environment. Is the interface completely

standard or does it permit definition of new functionality

to respond to the specific organisational needs?

Organisations will need to understand if the required

capabilities are supported.

Is it possible to exchange data and invoke

functionality between the individual cloud

services used by a customer?

As cloud services mature, companies will also want

to exchange information directly between two cloud

services to which it subscribes. This might, for example,

be to consolidate information from one service into

another or it might be to create a ‘composite’ service

offering more comprehensive capability.

Some better-known cloud service providers are already

implementing (or have implemented) APIs between

their services either in response to an existing need

or in anticipation of future demand. For example,

Google claims that salesforce.com can offer services

integrated with Google through its APIs. In fact, cloud

service providers may themselves make use of other

subsidiary cloud services to deliver the functionality

they need to support their services. This raises issues

(beyond the scope of this paper) about who precisely

has access to information held in the cloud and the

extent to which end customers are aware of other

subsidiary cloud service providers.

Therefore, customers considering cloud services should

examine and agree what level of interworking is actually

needed to support their business. In particular, where

the preferred cloud service differs significantly from

that currently in use, whether in terms of functionality

of ways of working, customers should consider the

impact of any loss of content, formatting or embedded

functionality arising from data interchange. This should

not simply be for a single information transfer but should

also cover information being passed back and forth

between cloud services or between cloud services

and legacy environments.

Is it possible to deliver a common authentication

mechanism across cloud and corporate services,

including directly between cloud services?

Sitting above and around both information exchange

and the creation of functionality, is the consideration

of access control. Whose role is it to control access

to cloud services and who can view, modify or delete

information handled by those services?

There are at present no hard-and-fast standards for

implementing access control. Microsoft, for example,

is able to extend a corporate Active Directory service

into its cloud services provision for a customer.

Google supports OpenID and is believed to support

alternatives through its APIs. Yet other services may

use authentication based on SAML/SAML2.

Authentication of functional / information exchanges

between two cloud providers on behalf of a single

customer are potentially more problematic. An option

might be to use a common authentication mechanism

such as OpenID but this is unlikely to provide the fine-

grained control most corporate applications are likely

to require. Some customers contemplating this kind of

information sharing currently believe that authentication

and authorisation will therefore need to be conducted

via their own infrastructure (a star-shaped architecture).

Potential cloud service customers should therefore

examine what identification, authentication and

authorisation will be needed to support their mixed

environment, whether factors such as single sign-on are

important and, through discussion with potential cloud

providers, agree on how best to deliver access control.

Cloud service evolution and potential

impact on interoperability

Making use of cloud services, whether to replace

existing services or provide new services, creates

expectations of, but also dependencies on, service

providers for evolution of their services. The positives

stressed by providers are that they will automatically

upgrade functionality without the pain that customers

might normally experience upgrading their own

infrastructures. So, in theory, a progressive service

provider will maintain their service at the leading

edge of technological capability.

7

8

But will this actually happen? And is it even entirely

desirable? What happens if functionality required to

support an in-house capability or a service from another

cloud provider is withdrawn or modified?

Many cloud providers will repeatedly improve their offer to

improve their competitive positioning in the market. More

and better functionality will become rapidly available,

and with this the underlying data and APIs will evolve

to suit, and this may make it difficult to ensure that the

interactions between different providers will continue to

work. However, vendors are demonstrating significant

maturity in sharing their standards and APIs, mostly

following significant anti-trust law suits, especially in the

USA, so much of this evolutionary pressure will be based

on out-competing the opposition rather than in locking

competitors out. Most word processors are now able to

exchange files despite the wide range of standards that

different vendors use, although differences mean that

some data and functional loss are likely as described

earlier in this section.

How a given service evolves is likely to be very

dependent on the ethos and aspirations of the provider.

What motivates them? Are they interested in innovation,

for example, or are they more interested in customer

lock-in – or both. Because of the ‘pain’ that may be

involved moving to the cloud, particularly in relation to

core ICT services, the hope has to be that a chosen

provider’s aspirations match those of its customers. Or,

more accurately given an individual customer is unlikely

to have much influence over a provider’s motivations,

that the customer’s aspirations and expectations

correspond with those of its cloud service providers.

For example, more dynamic cloud service providers

are likely to suit equally dynamic young companies

who enjoy being at the leading edge, but may be less

appropriate to more established organisations or those

for whom maintenance of legacy services is important.

“Evolution” with dynamic providers is more likely to be

through the periodic migration of old services and data

to new services rather than the parallel operation of

old and new. This has already been seen in 2010, with

Google announcing that after only 3 years they were

discontinuing development of their Gears platform,

before the replacement (HTML5) has been released.

Conversely, cloud service providers more sensitive

to corporate concerns about service continuity may

also be less dynamic, with the emphasis on legacy

and, potentially, lock-in than on delivering cutting-

edge technology.

There is no right answer to choosing which type of

provider might be more appropriate. As mentioned

earlier, it is as much an issue of cultural match as pure

technology. However, whatever route is chosen – and

it is not purely a binary choice – customers need to

remain conscious of the implications of their choice,

where it may be becoming deficient and where some

remedial action may be needed, such as moving to a

different cloud service provider.

The picture becomes yet more complex when multiple

cloud service providers are involved in delivering a

‘composite’ service. Will interfaces between services

continue to work appropriately as they evolve in their

own separate directions? Is there a risk that functionality

may be removed from one service which is critical to

the operation of another service? Could constituent

services diverge sufficiently to destroy delivery of the

composite service?

Unlike a conventional managed service provision,

most customers will have limited control over their cloud

service providers and how their services might evolve.

The cost advantages of cloud services derive from

standardised service provision and thereby achieving

economies of scale with the provider retaining control

over service evolution rather than delivering a service

tailored to the needs of individual customers.

If interfaces change as the underlying raw services

change then this could break links to other services.

The change may be one to which it is easy to adapt

or it could potentially be quite fundamental to the

operation of a composite service. This situation is likely

to be aggravated where two cloud service providers

have different sets of aspirations and move in different

directions. The implication, therefore, is that it is

important to ensure as far as possible that there is a

direct relationship between two cloud service providers

whose services are required to interwork. There should

be a joint commitment to ensuring compatibility. This

may well be difficult to achieve in practice other than in

a small number of instances, most likely between major

cloud service providers with compatible outlooks.

9

Extracting a service from the cloud

Cloud services need prenuptial agreements just like

marriages. What happens if and when the time comes

to move on? How does a customer extract its

information and bring it back in-house or transfer it to

another service provider?

While it is perfectly possible for a customer to extract its

own data from a cloud service, this does not necessarily

mean that it will be easy – or cheap. Many providers

charge for outbound data transfers by the gigabyte,

for example, and information may only be available for

extraction in the crudest forms. In choosing a service,

therefore, it is important to establish how, and in what

form, information can be extracted from a cloud service.

A structured data extraction is likely to be best and

high-capacity transfer mechanisms such as hard disks

and tapes may be more appropriate, than network

transfers for very large volumes of data. Furthermore,

network charges and bandwidth requirements could

rapidly become prohibitive or even impossible if a data

snapshot is required.

So entry into a cloud agreement should also pay due

regard to what a customer will need to do when the

agreement comes to an end or if it is terminated early.

What information will need to be extracted and how will

it be extracted? How will large data volumes be handled:

the growth of data hidden away in cloud services is

almost certain to come as a shock! Finally, what will

extraction cost? All these factors need to be discussed

up-front with a potential cloud provider and agreed

formally before entering into a contract.

Conclusion?Interoperability will be a challenge, but it is not an

insurmountable one. Common standards will ultimately

enable data, functionality and authentication to be

connected between multiple vendors and cooperation

will be essential to remain competitive in the market.

The key vendors are not naïve, interoperability is a

challenge that they are well aware of, and whilst they

each want to dominate the market, they are not being

destructive and killing the market by stymieing the

adoption of common standards.

That said organisations need to think through the

implications of interoperability. Several semi-compatible

standards are likely to compete in the near term, and

the acceptability of some data loss will need to be

considered. Furthermore, the service offerings are

still evolving rapidly and individual cloud providers

may not maintain significant backwards compatibility

in their APIs, resulting in functional breakdowns where

separate cloud suppliers upgrade dates do not coincide.

Conversely, where interfaces are heavily standards

driven, changes to the standard are likely to achieve rapid

upgrades across the whole network of cloud services,

in timescales that many non-IT specialist organisations

would struggle to achieve if services were in-sourced.

In the near term, many organisations might be able

to avoid the need to consider interoperability issues

by only transferring peripheral services to the cloud.

However, as a greater number and variety of services

are moved to the cloud, the number of links that need to

exist between the organisation and cloud applications,

and between multiple cloud applications will increasingly

make this a much more central issue for organisations.

To protect the organisation in the long term, it is

important to consider the questions that we pose

in this paper, understand the limitations and risks

that will exist, and mitigate against the impact of

these limitations. This will enable organisations to

make informed decisions about which elements of

their IT estate are suitable for moving into the cloud.

To speak to one of our cloud experts about interoperability issues that your organisation could face, contact us now cioinsight@paconsulting.com

www.paconsulting.com/cloud

10

Cloud Mobile Grid

11

PA offices worldwide

At PA Consulting Group, we transform the performance of organisations

We put together teams from many disciplines and backgrounds to tackle the most

complex problems facing our clients, working with leaders and their staff to turn around

organisations in the private and public sectors. Clients call on us when they want:

an innovative solution: counter-intuitive thinking and groundbreaking solutions

a highly responsive approach: we listen, and then we act decisively and quickly

delivery of hard results: we get the job done, often trouble-shooting where previous

initiatives have failed.

We are an independent, employee-owned firm of talented individuals, operating

from offices across the world, in Europe, North America, Middle East, Latin America,

Asia and Oceania. We have won numerous awards for delivering complex and highly

innovative assignments, run one of the most successful venture programmes in our

industry, have technology development capability that few firms can match, deep

expertise across key industries and government, and a unique breadth of skills

from strategy to IT to HR to applied technology.

• defence • energy • financial services • government and public services

• international development • life sciences and healthcare • manufacturing

• postal services • retail • telecommunications • transportation

• strategic management • innovation and technology • IT • operational improvement

• human resources • complex programme delivery

Delivering business transformation

Los Angeles

Buenos Aires

Beijing

Copenhagen

Stockholm

Oslo

Dublin

LondonCambridgeBelfastBirmingham

Manchester

UK:

MadisonBoston

Bangalore

Denver

New Delhi

Utrecht

New YorkPrinceton

Washington, DC

FrankfurtMunich

Wellington

San Francisco

DohaAbu Dhabi

Edinburgh

Corporate headquarters123 Buckingham Palace Road

London SW1W 9SR

United Kingdom

Tel: +44 20 7730 9000

www.paconsulting.com

This document has been prepared by PA.

The contents of this document do not

constitute any form of commitment or

recommendation on the part of PA and

speak as at the date of their preparation.

© PA Knowledge Limited 2010. All rights reserved.

No part of this documentation may be

reproduced, stored in a retrieval system,

or transmitted in any form or by any means,

electronic, mechanical, photocopying or

otherwise without the written permission

of PA Consulting Group.

01448-4