Post on 14-Jul-2020
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