1. Introduction

Issues about data – for example customer lists and purchase histories – have been relevant to competition authorities for decades.  But various technological developments have led to rather revolutionary changes in the amount and kinds of data that can be gathered and the ways in which that data can be analyzed and used.  So the era of so-called Big Data is likely to present new competition law issues.  But we’re fairly close to the beginning of the road of assessing how Big Data may raise competition concerns.  Having massive quantities of data and even achieving a great advantage in data scale does not inherently yield dominance or give rise to incentives to preserve that dominance through anti-competitive conduct.  Nor would the acquisition of a “data rich company” necessarily lead to dominance or significantly impede competition.

A number of instances might arise where data and scale will give rise to competition problems, but every situation will have to be addressed on its own facts.  There are three areas where data and competition law may intersect: (i) merger control and data; (ii) dominance cases involving data; and (iii) the use of data and concerted practices.  Each will be addressed in turn.

2. Merger control and data

There is a need to distinguish between two issues: (i) whether the existing Merger Regulation thresholds should be modified to require notification of data-driven acquisitions that are currently not subject to review by the European Commission (“EC“), and (ii) the assessment of potential harm to competition in cases that are subject to merger control (either under the existing thresholds or some new ones meant to capture more data-related deals).

At the beginning of October the EC launched a public consultation on the possibility of changing the existing Merger Regulation’s purely turnover-based notification thresholds.  Some have suggested that the purely turnover-based thresholds do not necessarily capture some transactions that could raise serious competition concerns.  For example, an innovative target with little or no income could be a tempting acquisition, especially if the acquirer can combine the target’s assets with its existing assets – perhaps including data — in a way that yields a competitive advantage – or, if by acquiring the target, an existing large market player can avoid disruption of the market by an innovative new competitor.

Potentially, the acquisition by an existing large player of another company with little current revenue but large quantities of unique data that is not easily replicable could establish barriers to entry and establish or maintain a dominant position.

In the pharmaceutical sector, an existing large player might be after a target pipeline; the target might have developed a promising new drug that’s not yet approved for sale (which might compete with the acquirer’s existing products).

In theory, acquiring a company with these kinds of assets might result in “a significant impediment of effective competition“, even though the company’s turnover might not be high enough to meet the Merger Regulation thresholds.  Nevertheless, one should be cautious about making changes to the merger notification thresholds.  It is important to find the right balance in order only to cover mergers that could have potentially negative effects on competition, without making life harder for innovative startups.

One key question is whether there really is any evidence that potentially anti-competitive transactions are falling through the cracks.  Some suggest that Facebook’s acquisition of WhatsApp in 2014 presented an example of a gap in the EC Merger Reg.  Facebook paid USD 19 billion for a company with 600 million customers, but the merger did not need to be notified to the EC because WhatsApp’s turnover was too low. Other than Facebook/WhatsApp, which is not necessarily the best example of a case proving a need to change the EU thresholds because the case was ultimately referred to the EC by the national competition authorities of three Member States, there seem to have been no cases suggesting there is such a need.  As such, there does not seem to be any concrete experience demonstrating the jurisdictional rules should be changed in order to look beyond turnover as a means to identify whether or not a merger should be notified.

It should be noted that Germany is moving on this front.  The Government published a proposed amendment to the German Antitrust law for a new merger control notification threshold based on transaction value.  The German proposal resembles the size-of-transaction test used in the United States.  One question that arises in this context is this: why, if a size-of-transaction test works in the U.S., would it be so bad for one to be adopted by Germany or the EC?

3. Dominance and data

Second, it is worth considering data in the behavioural context.  There are two aspects to it:

(i) Can controlling data and having a large advantage in data scale give rise to dominance?

(ii) To what extent can a dominant company’s conduct related to data restrict competition?

  • Dominance

Controlling data and having a large data scale advantage does not inherently yield dominance.  Nevertheless, achieving scale in data may create barriers to entry and can be a means to establish or strengthen market power.

Search and search advertising is one area with which the EC has become very familiar over the years (going back at least to Double Click).  Thus, the search and search advertising areas are more ripe than any others for addressing the consequences of data and scale and may well present differences from how scale and data is or should be analyzed in other areas.

In search, having a huge scale advantage in query-related data will yield dominance, and a dominant search company’s interest in retaining its data scale advantage and buttressing barriers to entry – and to monetize its data in ever-expanding ways – will give rise to incentives to engage in conduct that might be deemed unlawful under the antitrust laws.

In relation to search engines specifically, it is query scale – not technology – that is the primary driver of search engine profitability and competitiveness, due in particular to machine-learning aspects of search.  Search algorithms learn from user queries and how users interact with search results, and the greater the scale advantage with respect to number of queries (in particular so-called “long tail” queries), the more relevant results the search engine will be able to show to users.

This helps explain why barriers to entry can be so high in a search engine market where one company has an overwhelming advantage in scale of queries.

  • Conduct

Having considered dominance, it is also necessary to examine to what extent a dominant company’s conduct related to data can actually restrict competition.

Can foreclosing competitors’ access to data constitute an abuse?  Many argue that this depends on the type of data, and its replicability.  This has already been analyzed in the merger context: if the data acquired by the acquiring company from the target is easy to obtain from other sources, then there may be no anti-competitive effects.

What if a dominant company changes its privacy practices to combine sources of data that gives it abilities to monetize that data in ways no competitor can match?  Might this be an exploitative abuse under Article 102?  And if it forecloses competition by other advertizing competitors, might it be an exclusionary abuse?

4. Concerted practices and data

A third example of potentially infringing data-related conduct arises in the context of potential concerted practices.  What if competitors on the market used artificial intelligence means to determine prices?  Let’s say those tools determined that the most profitable way to respond to an increase of the price by a competitor would be to increase one’s own price (rather than keeping one’s price down to capture a higher volume share).  There would be in principle no agreement between companies themselves, yet the result for the consumers would be an increase in prices.

5. Conclusion

Many data-related antitrust questions and interesting debates are still to come.  Some instances might arise where data and scale will give rise to competition problems, but every situation will have to be addressed on its own facts.




Author – session moderator (more detailed report by the subject matter expert, Adrian Weller, to follow)

Artificial Intelligence (“AI“) is not a new phenomenon; it has been around for at least 50 years as possibly the grandest of all challenges for computer science.  Recent developments have led to AI systems providing remarkable levels of progress and value in different areas – from robotics in manufacturing and supply chain, to social networks and e-commerce, and systems that underpin society such as health diagnostics.  As with any technology there is an initial period of hype, with excessive expectations and then a period of reality and measurable results – we are at the beginning of such a period right now.[1]  Recent progress has been enabled by three factors:

  • Advances in algorithmic theory;
  • Greater computational power; and
  • Availability of data

Our session focused on three questions – (i) how do we deal with liability; (ii) how can privacy be respected; and (iii) how can we achieve a greater degree of transparency and accountability in algorithms and avoid discrimination.  Algorithms arguably need to attain a “higher” standard than humans, they need to be more transparent than “human decision making” and while they may follow the same logic as humans they should be held to account.

First, with regard to liability, it is important among other aspects, to consider the complex supply chain in AI services.  The self driving car is a good example.  In the case of an accident, who is at fault – the software developer, the manufacturer or the driver?  AI agents are rather like children, they are strongly influenced by what they learn from data – outputs can be substantially changed depending on the data set used.  Examples are the Tay chatbot that emitted hate speech after being exposed to Twitter.  It is therefore important to consider what standards of behavior are appropriate and what actual normative standards should be in place.  In addition, algorithms should be inspected at a technical level, so that the reasons for malfunctions can be established.  From a legal point of view, a key consideration is whether algorithms have a legal personhood.

Second, with regard to privacy, it can be said that we live in an age where “tracking” and various kinds of surveillance have become commonplace.  Health apps are widely used and our phones collect and transmit large amounts of data about us.  Giving up personal privacy, while maybe not such an issue for today’s millenials, can clearly have significant consequences down the road (think Facebook).  The ability to manage one’s data, and third party data ownership are important factors in this regard.  Who actually owns your data?  For instance, if you allow a smart meter to be installed in your household, who owns the data collected about your energy usage and patterns and who is given access to it?  Has the data been retained by the primary business group or is it passed on to third parties?  If data is “tweaked”, how does this affect ownership since it has been transformed?  It should be noted that tweaked data can be used to train algorithms.

What about the “right to be forgotten” as set out in data protection laws including the General Data Protection Regulation (“GDPR”)?  And, if your data has been used to train an algorithm, what happens when your data is erased?  Does this erasure influence the output?

Another growing area of interest is the concept of “Differential Privacy” and the potential to mask certain data fields.  This will be covered in a follow-up paper.

Third, with regard to transparency, a key concern is to ascertain “how well” an algorithm is working, set against its original objectives.  Can a system be trusted?  Why was a specific recommendation made in one decision instance?  Is the algorithm “fair”?  What about instances of bias in the system, which may be influenced by certain attributes such as gender or ethnic origin? A good example would be an application for a bank loan online, which may refuse credit to minority groups and cause follow-on adverse impacts on an individual’s ability to get credit.  Another example is the COMPAS recidivism risk prediction system used in the US to help decide whether parole can be granted.[2]  This has been claimed to be biased in certain ways in terms of race.  How do you remove bias from such systems to avoid discrimination?  Is the right approach to delete certain data fields, or to add other data fields to make the system fairer?  Arguably it can be said that humans are by nature biased so is it possible for AI systems to function better?

In the follow up discussions we also discussed the European regulatory context.  A key consideration here is that AI is changing very rapidly and policy actions tend to lag behind.  As such, there is a risk that regulatory action by the EU as in other technology areas, may fall behind the curve of technological development and deployment.  It is therefore difficult to imagine how such regulatory intervention in the EU would usefully guide the development and deployment of AI systems in a meaningful and timely way.

On the other hand, key issues underlying AI, such as data protection, safety and security, liability, and accountability are already to a greater extent than is immediately obvious, covered by current and soon to be implemented legal frameworks.  A good example of this is the GDPR, that will take effect as law across the EU in 2018 and will restrict automated individual decision-making (that is, algorithms that make decisions based on user-level predictors) which “significantly affect” users.  The law will effectively create a so-called “right to explanation,” whereby a user can ask for an explanation of an algorithmic decision that was made about them (see Goodman, Flax et al).[3]

Policy action should make sure that society can take full advantage of the capabilities of AI systems while minimizing the possible undesired consequences on people.  Safety is very important, as well as fairness, inclusiveness, and equality. These and other properties should be assured of in AI systems, or at least we should be able to assess the limits of an intelligent machine, so that we do not “overtrust” it.

It is therefore of utmost importance for societal well-being that policies and Regulations help society use AI in the best way.  Ethical issues, including safety constraints, are essential in this respect, since an AI system that behaves according to our ethical principles and moral values would allow humans to interact with it in a safe and meaningful way.

While it is clear that a complete lack of Regulation would open the way to unsafe developments, this may not be the case in the EU due to the strong legal framework that will frame the development and deployment of AI.

[1]              http://www.nextgov.com/emerging-tech/2016/12/microsofts-new-plan-flood-your-entire-life-artificial-intelligence/133908/?oref=nextgov_today_nl

[2]              https://www.nytimes.com/2014/02/17/opinion/new-yorks-broken-parole-system.html?_r=0

[3]              https://pdfs.semanticscholar.org/25d7/d975a12fd657b4743acd262cbdfe2dc2e6e9.pdf

November 28, 2016 @ 2:51 am

Our first of a series of ECIS events on the opportunities and challenges of big data and data flows is taking place next week. We’d be pleased if you can join us!

Clifford Chance LLP, Avenue Louise 65, 1050 Brussels
Tuesday 29 November 2016
15:30 to 18:00 followed by a cocktail reception

In this session, we’ll be examining two topical issues – the role of competition law with regard to merger control for “data rich” companies. How do you evaluate the value of data?
The second topic is the ever increasing importance of Artificial Intelligence, what are the opportunities and challenges in Europe with regard to free flow of data and innovation?

The format will be a round table – our experts sharing their views on the topic and in each case a response from industry and European institutions.

  • Thomas VinjeECIS Legal Counsel and Spokesman

Thomas will share his views on data and competition law, including the Commission proposal for new thresholds on mergers.

  • Adrian Weller Senior Research Fellow, University of Cambridge; Faculty Fellow, Alan Turing Institute; Executive Fellow, Leverhulme Centre for the Future of Intelligence

Adrian will discuss the innovation potential of Artificial Intelligence, in particular the field of machine learning, the role of data, and the legal implications.

Networking cocktail
Please join us afterwards for networking reception

Please RSVP to info@ecis.eu, or telephone Désirée van Dyk at +322 533 5930.

ECIS website: http://www.ecis.eu/


ECIS welcomes the Data Protection Code of Conduct for Cloud Providers which was published in near final draft this week. We look forward to a swift completion of the outstanding tasks. The code sets a high standard for data protection and  security, and will help build confidence between cloud users and suppliers.

Link to EU site: https://ec.europa.eu/digital-single-market/en/news/data-protection-code-conduct-cloud-service-providers


“Cloud Switching” and the free flow of data – portability and interoperability of software and data across cloud services

When deciding how to implement and deploy cloud computing technologies, enterprises must consider how easy it will be to access and move software and data components to adapt to current and future needs.  This document outlines aspects of interoperability and portability in the context of cloud computing.  It also explores attributes of cloud computing that address issues that enterprises face in accessing and moving software and data in cloud computing, as well as provide some background and context for making informed decisions.  Particular consideration is given to “hybrid cloud computing”, an increasingly common paradigm that enterprises are adopting for their cloud solutions.  Hybrid cloud solutions involve a mix of multiple cloud services or resources that can be deployed to both public and private systems, often in combination with existing enterprise systems.


Previous ECIS papers[1] provide a basis for understanding important aspects of cloud computing, and to highlight potential issues that can restrict the value of cloud solutions.  As interest in cloud solutions has grown, technology has evolved to broaden the scope of where cloud services can be used.  This evolution has expanded capabilities in many ways.  For example, many enterprises seek to maximize their ability to adapt to changes in future needs while simultaneously being able to leverage existing investments in software and data.  These different capabilities often have unique dependencies and requirements, and vendors have introduced many enhancements designed to improve the ability of their cloud platforms to meet such requirements.  This “multi-dimensional” approach has led to the concept of the “hybrid cloud”.

As described in previous ECIS documents[2], even relatively homogenous cloud platforms can manifest limitations that can potentially impact competition and customer choice within the Information Technology market merely by the manner in which a cloud service is architected and/or deployed.  Also, the importance and value of data itself has continued to increase, in contrast to the software which operates on the data; this is one of the main reasons for the interest in adapting cloud solutions to leverage existing infrastructure.  With the evolution into an increasingly heterogeneous model, both in terms of software as well as data, hybrid cloud solutions require additional considerations in order to realize the promise of cloud computing.

The definition of “hybrid cloud computing”

Definitions are usually of paramount importance to understanding technology.  As is often the case with a new idea, especially one that is popular, it can be difficult to develop consensus for the term ‘hybrid cloud’.  The word ‘hybrid’ literally means “a thing made by combining two different elements”[3].  However, such a broad definition leaves significant opportunity for confusion (and abuse).  Fortunately, there are efforts to provide common definitions for cloud computing that reduce ambiguity, including ‘hybrid cloud’:

“Hybrid cloud is a deployment model using at least two different cloud deployment models”[4]

A cloud deployment model is a way in which cloud computing can be organized based on the control and sharing of physical or virtual resources, and includes public, private and community clouds.  With hybrid cloud, the cloud deployments remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability.  For many uses, hybrid cloud is a combination of private cloud and public cloud deployments, often including integration with existing on-premises enterprise systems.

With this definition as a basis, an appropriate understanding of relevant concepts is easier to develop.  Some examples of such related concepts include portability and interoperability.

Portability and Interoperability

Two related, but very different, attributes of a component within a computing system are portability and interoperability.  Portability is “the ability of software or data to be transferred from one machine or system to another”[5].  Interoperability is “the ability of two or more systems or applications to exchange information and to mutually use the information that has been exchanged”[6].  Portability defines the ability to physically move software or data from one system to another.  Interoperability defines the ability to interact between systems via a well-defined interface to obtain predictable results; the software or data continues to reside on the same physical machine after the interaction.  Each of these capabilities is important for any given cloud solution, depending upon the specific business requirements.

For example, an enterprise may have a large database of information within their own enterprise that they wish to use with a new cloud solution, but they want to continue to maintain control of their valuable data within their own datacentre.  For such a solution, interoperability between the cloud service and the database is of prime importance.  The same enterprise may also be building another cloud solution for a brand new market they are considering expanding into.  This new market is nascent, so the enterprise wants to minimize the amount of funds they risk for their exploration.  For this solution, a public cloud service can offer an attractive value because only the resources actually used must be paid for and the amount of resources used can be scaled to match the exact number of customers using the solution.  However, if the new business proves successful, the enterprise may wish to be able to move the software from the public cloud into their own datacentre at some point in the future.  For this solution, portability of the software and/or the data between the public cloud platform and their private cloud infrastructure is of prime importance.

Software portability vs. data portability

Portability is often discussed for software (or “applications”), but the portability of data can also be of significant importance.  Changes to business strategy, market successes or failures, and new regulatory requirements may require relocating data to different geographic locations.  Another consideration is the sheer volume of data that is created; some datasets may grow so large that it makes more sense to move the software functionality that uses the data instead of the traditional model of moving the data to the software.  Thus the ability to move software and data individually has inherent value.

Software portability is usually affected by the dependencies the software has on other computing components such as “middleware” software runtimes, operating systems, databases or hardware architectures.  Software portability is made more difficult in cases where these dependencies change in some way when moving from the source system to the target system, for example a change in the hardware architecture or a change of operating system.

In a similar manner, data portability is affected by the format and content expected and supported by the target system.  This is sometimes influenced by the nature of the data storage system, but more commonly it is influenced by the software that interacts with the data.  How intimately data is related to the software that uses the data depends upon a number of factors, and is primarily determined by architectural design decisions made during software development.  For cloud computing, these decisions may be constrained by the type of cloud service model[7] being used.  IaaS and PaaS solutions can utilize technologies such as file systems and DataBase Management System (DBMS) technologies, which must also be available in the target system in order for data to be portable between one cloud service and another.  SaaS solutions by definition contain the software that operates on data, and this software usually dictates the content and format of the data used by the cloud service.

Further, it is critical to understand that the portability of software or data is not a simple “true or false” metric.  The level of ‘portability’ (as a measurement) can be defined as the “amount of effort required to move from one system to another”.  For software, if the source and destination systems are running the same operating system and hardware the “portability” is likely to be easy, perhaps as simple as copying some files.  However, if the source and destination systems run a different operating system on different hardware, it may take considerable effort for a large team of people to make the changes necessary for the software to work on the destination system.  Both examples are technically “portable”, but obviously one is more “portable”, and therefore will cost much less to move.  The more extreme scenario is typically referred to as ‘software migration’.

Data portability can be measured across a similar spectrum, depending on the capabilities of the file system or data management software and also depending on the requirements of the software interacting with the data on the target system.  If the source and destination cloud services store the data in a common format (“common syntax”) the data is likely to be easily transferred between them, perhaps as simple as copying some files between the source and destination cloud services.  Other cloud services may require an “export/import” process, where data is converted to a format suitable for the destination cloud service- which may be a standardized interchange format.  Such a process can take a long time, especially for large data sets.  In addition to the data format, there is the question of whether the data has the same meaning between the source and target cloud services (“common semantics”).  Portability is likely to be more complex in the case where the destination cloud service requires different content than the source is capable of providing.  Finally, a target cloud service may require data to be loaded via a custom interface; in this case special software may have to be created to move data from the source.  As is the case for software, there is a spectrum for data portability that can require a variable amount of effort, cost and risk to enable.

Portability and Interoperability directly affect the ability to switch cloud vendors

Many vendors offer cloud services.  However, even cloud services which offer similar capabilities don’t always have identical interfaces, even though many technologies exist to enable interoperability between cloud services.  Many cloud services use common interoperable protocols; for example, many cloud services have interfaces that use ReST over HTTP (or HTTPS), which is a well-known and popular standard.  However, the interfaces offered by the cloud services using these protocols are not typically standardized- and there are often detailed differences in the way in which individual service operations behave.

It is differences in the interfaces offered by different cloud services that make interoperability between one cloud service and an alternative cloud service difficult.  If a cloud service customer adapts their systems to work with one particular service, they may not be able to choose an equivalent cloud service from a different provider without having to adapt their systems again for the new provider; this limitation is due to the lack of interoperability.

Portability is also a critical attribute of a cloud service that directly dictates a customers’ ability to choose alternative cloud service providers without making extensive investments to change or adapt the software and/or data component(s) so they can be used on a different cloud service.  The cost, time and risk of adapting existing software and data must be taken into account when considering switching cloud service providers.

In order to interoperate with a service or porting data and applications between providers, many considerations need to be taken into account.  Issues such as transport protocols, encoding syntaxes for communication messages or data, semantics, and organisational and legal policy issues need to be addressed.  Of these, semantics is key as without a mutual understanding of the data being exchanged or ported, or without a mutual understanding of an expected outcome when two systems interoperate, interoperability and data portability will be ineffective.  As such, when switching providers or porting data, it is essential to establish a mutual understanding of (i) the exchanged data and, (ii) behavioural semantics.

The ability to switch to alternative cloud service providers is not restricted solely to customers that seek lower prices or better value.  Cloud service providers are also enterprises themselves and they may change their offerings based on their own business requirements, which may not align with those of their customers.  Before cloud computing, enterprises owned and managed their own infrastructure, so once a system was deployed the enterprise could be relatively confident they would enjoy its functionality for the planned lifetime of that system.  One of the values of cloud computing is that customers no longer have to maintain their own infrastructure, and they can pay for only the actual resources they consume.  However, a significant downside to this model is that the customer also becomes fully dependent upon the capabilities offered by the cloud service provider.  If the cloud service provider modifies or stops offering a feature or interface that a customer relies upon, the customer may be forced to incur significant costs to simply keep the solution they already had.

Enabling the free-flow of data, without restriction

In addition to being able to place and move data to the most appropriate location for existing business requirements, another aspect that should be considered is the potential unknown future value of data.  The evolution of most technologies has at some point involved finding a completely new use for existing resources, and many of these new uses could not have been predicted.  Historically it has taken considerable effort to adapt software and data to be useful in ways beyond that originally envisioned.

Many technologies have been developed to attempt to improve the flexibility and agility of adapting resources to new scenarios, and this goal has been a driving force in the evolution of cloud computing since its inception.  Most traditional enterprise systems – before cloud computing – have focused on adapting the interoperability of systems as opposed to the portability of data.  With the advent of cloud computing the pace of technological innovation has dramatically increased.  This places an ever-increasing importance on the ability to “repurpose” software and data for new usage.  Restrictions in the free-flow of data via the lack of interoperability – and increasingly via the lack of portability – impede innovation and limit value.

Considerations for evaluating interoperability of cloud services: functional, administrative, management and business capabilities

When it comes to interoperability, there are multiple, different interfaces between a customer and a cloud service provider, as shown in the Figure on page 2.  The functional interfaces (which may include human user interfaces as well as programmatic interfaces) are made available to access the service being offered, and they allow the customer to perform its business activities that necessitated a cloud solution.  To ensure the smooth operation of the customer’s use of cloud services, and to ensure that those cloud services are running well with the customer’s existing ICT systems and applications, administration interfaces are also provided.  Finally, business interfaces are typically used to allow a customer to perform functions such as discovering and selecting appropriate cloud services, invoicing and paying for usage, and other financial and legal activities.

While the underlying technologies for each type of interface may be similar, different considerations may need to be taken into account.  The business interfaces must work with existing in-house enterprise systems, and the administrative interfaces must work with in-house IT management systems – these are typically “off the shelf” IT management solutions. Each of these interfaces must be compatible with the in-house systems, or must by adaptable to them via the use of integration technologies. There are two challenges to interoperability here:

  1. What happens when you want to change cloud service providers?
  2. What happens when you want to replace an in-house system?

The more a customer can rely on standard interfaces, the more flexibility they will have in switching cloud service providers as well as switching between different in-house systems.

Exploring aspects of portability and interoperability relative to IaaS, PaaS and SaaS

Interoperability concerns, challenges and issues are largely similar regardless of the type of service being used.  While functional and user interfaces are likely to change because of the nature of the service, the business functions are likely to be very similar.  Administration interfaces will differ in the types of entities that can be managed, but the style of these interfaces is likely to remain the same, based on commonly used existing management systems.

When it comes to portability, the type of service being used determines the degree of software and data portability available. There is a spectrum in terms of ownership and management of hardware resources, software and data.  In a pure in-house system, the customer owns and manages all of these and has total responsibility. At the other extreme, SaaS customers have no ownership and perform little management of hardware resources or software, and only have access defined by the interfaces that the provider chooses to make available.  Progressing between these two points, IaaS offers the management of virtual machines, storage and networks, where the customer usually has substantial control over their data and the software components they load into the cloud service. For PaaS, there are fewer resources to manage as they are abstracted by middleware. Here the data is still largely in the customer’s control, but it is likely that the customer will choose the target cloud service on the basis of the middleware features provided (e.g. a particular DBMS, or a particular runtime) in order to ensure compatibility with existing software components and datasets.

Software portability is not a concern for SaaS by its very definition (the software within the cloud service belongs to the cloud service provider) and data portability depends on the interfaces offered by the provider for loading and unloading data, including the data formats offered as well as their semantics.  IaaS services usually provide straightforward software portability, since the resources provided are lower-level and support most common software frameworks.  Hardware architectures can be a concern, since differences between hardware may require adapting software and/or data to the destination cloud service. For PaaS services, there is often a focus on software portability – usually the destination cloud service provider is chosen specifically for their support of the necessary software frameworks and middleware; without such support, the customer would face the substantial task of adapting their software to use different frameworks and middleware.  Depending on the architecture of the software that is running on a PaaS service it may be possible to port data independently from porting the software, especially if the data is held in standardized file systems or databases.

Hybrid cloud solutions place increasing importance on portability and interoperability

Throughout history, a common trend in technological evolution has been to “decompose” larger systems into smaller parts.  There are many reasons for this trend, but a common one is to be able to leverage the functionality offered by the smaller part in more ways.  For example, rather than having every single cloud service provide its own mechanism to authenticate users it makes more sense to have one service that authenticates users for all cloud services.  Over time this decomposition happens continually- the parts get smaller and smaller, and are used across more and more other services.  The end result is improved efficiency and operation but with an ever-increasing inter-dependency across numerous services.  A failure of any one of the small parts can impact a large number of dependent services.

Another parallel trend is the creation of wholly new capabilities, which can be used to extend existing applications and solutions to cover new areas previously not possible.  Recent examples include the creation of “cognitive computing” services, which are able to bring artificial intelligence techniques to bear on unstructured or semi-structured data.  These sophisticated capabilities are now offered as sets of cloud services, which can be “plugged into” existing applications to give them the ability to service businesses in new and important ways, without requiring extensive new development activities.

Hybrid cloud solutions offer great agility, flexibility and value, but they also increase the inter-dependencies across applications and the many cloud services they depend upon.  It is clear that as these inter-dependencies increase, the ability to move and connect all the various cloud “parts” becomes more important.

Standards hold great promise to enhance interoperability and portability for cloud computing

It is clear that interoperability and portability are both very important to realize the full value of cloud computing.  Having a common, standardized definition for the mechanisms that are used for different systems to exchange information has enabled countless technologies to thrive.  The Internet itself would never have been possible without the TCP/IP networking standards, which allow any and all computers to connect to each other- much like any telephone in the world is capable of connecting to any other telephone.  With the multitude of vendors offering cloud services, interoperability and portability will continue to grow in importance- especially as customers become increasingly dependent upon those cloud services.

Although there are already many standards defined for specific technologies used in cloud solutions, there are also efforts underway from leading standards organizations to clarify definitions, create common formats for improved interoperability and define specific contexts that vendors can adopt to improve compatibility and portability across a wide variety of cloud solutions[8].  For example, security, management and status monitoring are general concepts that are applicable- and important- across all cloud services.  Differences between vendors and their cloud services in any of these areas can have significant effects on the overall interoperability and portability of all the cloud solutions using those services.  By having common, well-defined standards across multiple cloud services enterprises will have better options and more choices in meeting their needs as technology and markets evolve.

The Digital Single Market and the Hybrid Cloud

The various components of the Digital Single Market (DSM) Strategy, which was adopted in May of 2015, include efforts to remove “constraints on the ability of individuals and businesses to move from one (on line) platform to another” and a “’Free flow of data’ initiative that tackles restrictions on the free movement of data for reasons other than the protection of personal data within the EU and unjustified restrictions on the location of data for storage or processing purposes.”  In addition, the DSM seeks to “Boost competitiveness through interoperability and standardization.” In a similar timeframe, the General Data Protection Regulation (GDPR) has become EU law – and while one of its major goals is to ensure appropriate treatment of personal data, its second major goal is to ensure the “free flow of data” within the EU.  The GDPR contains an explicit requirement for a data subject to obtain and transfer their personal data in a “structured, commonly used, machine-readable and interoperable format”.

As this paper demonstrates, the concepts of interoperability and portability in the context of cloud computing are nuanced and require care when applying them in public policy. For example, determining whether software or data is “portable” cannot be answered with a simple yes or no.  It is rather a question of determining the degree of interoperability and portability on a sliding scale, with the answer ranging between “very difficult” to “relatively easy”

Regarding interoperability, while the Commission is to be commended for exploring avenues to promote it, it is necessary to understand that this is a complex topic involving numerous types of interfaces.  It is important to note that the growth of hybrid cloud deployments will increase pressure on vendors to provide better levels of interoperability.  Understanding and channeling that pressure through the global, industry-led standardization process will be critical.

As a final comment, although this is a complex topic it is important to keep policy considerations regarding interoperability and portability in the cloud focused at a broad EU level.  The Commission is to be commended for continuing to keep this topic on its agenda.  As was apparent at the recent DG Connect-hosted Consultation Workshop on the Free Flow of Data[9] of May 18, 2016, a large number of cloud vendors will happily avoid this topic and its relevance, and instead seek to avoid engaging with policy makers in terms of specific measures that could be adopted.

There is still much work needing to be completed to ensure an open, thriving market.  ECIS shall continue to engage on this topic.



Follow ECIS

Privacy Preference Center


Cookies that are necessary for the site to function properly.

gdpr, wordpress_{hash}, wordpress_logged_in_{hash}, wordpress_test_cookie, wfvt_{hash}, __cfduid


Cookies used to track user interaction and detect potential problems. These help us improve our services by providing analytical data on how users use this site.

_ga, _gid, _gat, collect