Last week saw a "Data Access and Transfer" workshop happening in Brussels, organized by the European Commission's Directorates General for Justice and Consumers (DG JUST) and Communications Networks, Content and Technology (DG CONNECT). The intent of the workshop was to understand if and how the EU should look at policies around data access and APIs. In terms of putting this into context, you can think about this as something that's similar to what PSD/PSD2 did for the banking sector, but not being limited to such a narrowly defined vertical.
Being new to discussions on the EU level (and the policy space in general), it seemed strange to see open data and APIs being treated differently; after all, at the technical level it makes a lot of sense to see open data and data access as simple forms of APIs. However, in the policy space it seems that separating these issues is a standard move, because it separates relatively simple features from more complex ones, and thus helps with acceptance and adoption. More practically speaking, if you ask government agencies to make data openly available, they are much more likely to be willing and able to do it, than if you ask them to also implement APIs that allow querying, data error reporting, and subscriptions to data updates.
In addition, the main hurdle in many cases is not the technical aspect of data access only or more complex APIs. The biggest problems pretty much always seem to be around data ownership and access to data based on ownership. A popular example is that of cars: All modern cars are connected and continuously gather data. That data is collected and controlled by car manufacturers. It would be very useful for both part suppliers and car owners if that data were available: suppliers could learn much more about how their parts are being used and perform in practice, and owners could do with their data whatever they like, for example for better understanding how the product that they paid for is functioning.
It was fascinating to be in the room with many people mostly thinking about what should be possible to do with data and APIs. Usually, my day job is to think about how to do well whatever it is that organizations want to do with APIs. My personal way of framing this is to talk about "doing good with APIs" vs. "doing APIs well", and of course both are important issues when it comes to data access and API strategies.
Unsurprisingly, there was some mention of the usual suspects Google and Facebook and other major data powerhouses. As we have seen in the past, the EU tends to take a tougher stance on what these companies can get away with and monetize, and how much they have to give some level of control to their users which are their main monetizable asset.
I had a speaking slot and thus the privilege to address the workshop audience. My main message went as follows, trying to explain why organizations are interested in APIs nowadays, what they are planning to realize the potential of APIs, and how they are moving forward with their API strategies.
Why?
Regarding "The Three Drivers of the API Economy", the main takeaway is that organizations are pushed towards APIs to increase their competitiveness, are pulled towards APIs because the API economy keeps growing and participation thus becomes increasingly valuable thanks to the network effect, and that following the leaders has become a safe thing to do because of the maturity of API products and technologies.
The EU is at a different scale (and level) from the organizations that usually think about APIs, and because of its size and diversity, considerations necessarily are different from what more clearly bounded organizations look at. Mehdi Medjaoui, who was present as well, thankfully pointed to the theory of the firm in that context, which considers how organizational boundaries are a result of market structure and transaction costs. I will leave it to more economy-minded minds to think about what that actually means when thinking about APIs and how they reduce transaction costs, the EU as a "meta-organization" with a mandate to define (some) market mechanisms, and what the best strategy looks like in this environment.
It is clear that APIs and their role in how organizations do business have had a huge impact on the economy already. Whether the push/pull/follow view mentioned above can be applied directly at the EU level is a complex issue to decide. But as a starting point it may be good enough to simply watch what others are doing, and think about if and how any of this could be of interest at the EU level.
What?
In order to reap the benefits of APIs, there are many different ways in which API strategies can be defined and executed. And of course it always depends on the context whether a strategy is a good solution or not; there is no single best strategy that fits everybody. On the other hand, from big organizations and really big IT systems such as the Internet and the Web there are a few key lessons that we can learn when it comes to what to look out for in an API strategy.
Decentralization means that in order to provide a dynamic evolving landscape, the focus should be on a decentralized architecture. If communities or domains decide that it is in their best interest to build centralized solutions, then these will simply become components of the bigger decentralized landscape.
Diversity means that APIs most importantly are a mechanism to reduce transaction costs. Standardizing on specific technologies reduces the potential for new domains to find solutions that work best for them. Better allow diversity, set some architectural patterns as guidelines, and then track the evolving landscape of how data access and APIs are being practiced.
Discovery is often necessary for scenarios where decentralization is a foundational principle. It removes centralization from being a starting point, to being a useful (and often essential) service that can evolve over time. This principle can be compared to search engines on the Web.
Description helps with scenarios where diversity is a foundational principle. The more data and API providers are self-describing, the better discovery services can be built. Description can be based on an evolving set of principles (similar to the voluntary self-description with
schema.org), and then can be used to understand the evolving landscape of services and its diversity.
How?
This is the part where the EU could make sure that it fosters a diverse and thriving ecosystem, by helping those participating in it to do it well, and thus by reducing friction in the API economy. As mentioned above, this does not answer the "How to do good with APIs" question, but it does provide guidance for "How to do APIs well within the EU".
Issues such as labelling and best practices are typically considered in API strategies. In good API strategies, they are not so much intended to be rules about what people have to do, but instead are derived from practice and trends, and thus help to understand and foster an "API Culture".
The main goal for this "how" part thus could be to help people using APIs well, instead of focusing on regulation when they have to provide data access and APIs.
The good news are that separating "doing good with APIs" and "doing APIs well" is not only possible, but probably also a good way forward. While it may take a while to figure out if and where data access and APIs should be regulated, it could be a smart decision for the EU to help reducing friction in the data and API market, very similar to how it has reduced friction in other markets.
Whether reducing this friction will be mandated or voluntary probably will take a while to figure out. But getting started with reducing friction could be literally done today, using the strategy outlined above. And the insights derived from this would be invaluable for any decisions that maybe will have to be made later on. For example, should it become desirable to mandate certain kind of APIs on the technical level, it certainly would be useful to have some insight into the current landscape.
What Next?
As mentioned initially, it was a great experience to have some insight into the big machinery behind the EU. From my personal perspective, I sensed a bit of the same hesitation that we sometimes feel in companies: They want to do APIs but are not quite sure what to do. They want to first define the perfect API strategy before they do anything.
Our usual response to this is: Start now! Start small and learn along the way. Start in a way so that you can adjust. Build a small and nimble ecosystem of components that can evolve and adjust. And then keep doing that. This is as good as it will get, do not expect to ever "be done" with your API strategy and then you can just execute. Part of executing an API strategy is to adjust it, based on the observations and insights into the API ecosystem.
It seems that this guidance may be even more appropriate for something as big as the EU: In order to anything based on reality, some insight is required into what is already happening. In order to reduce friction in the EU API economy, some guidance is required that helps people to provide well-designed data access and API services.
Many organizations have recognized that at the very least, guidance is helpful. And of course guidance is available for free (and this is a tiny subset of what is freely available):
- Web Data gets you started with five simple principles for webby data.
- W3C's Data on the Web Best Practices help those who want to understand how to make data available on the Web.
- The API Stylebook is a collection of API guidelines that organizations have made openly available.
It remains to be seen what the next step will be. If any resources are assigned to the general topic of "data access and APIs" within the EU, my biggest hope is that they would be divided between those that get to decide on the "where to do good", and those that think about the "how to do it well". The latter ones should go to work immediately and start doing for the context of the EU what modern organizations have been doing for the last few years: Figure out how to be in the best possible shape to create, foster, and participate in an API economy.
Comments