Drivers of the API Economy

Over the past few months I've been focussed on the "API -Economy". It's become clear to me that API's have several business drivers - and they're not all just about directly making money. Regulators are now playing an increasing part in the spread of APIs.

In this blog I'll try to capture the three main influencers in the API economy and how you may see their affects . I'll focus in on the regulators role as it's not often discussed.

Architectural Best Practice

At the moment 8 out of 10 API projects are internal. By internal I mean use-cases where the goal of the project is to allow access to a resource (usually a good ol' fashioned SOA style Service) to an internal party. So, why is that ?

I would suggest that APIs are a natural evolution of SOA. In previous entries I've discussed the constituent parts of API Management. The only element that's new in those is Monetisation - and even that's arguable. 

The API evolution has allowed us to do is all the things we were doing before but, I would like to think, from a slightly more business perspective.Rate limiting is a great example of an API-Management feature that was being done before but it now easier to define and implement. API Management allows the API-creator to define, at a higher/business level, those rate limits and then the API-Manager tooling implements. This is removing the  requirement for the lower-level developers and sys admins to get involved in the basic cases. They no longer need to write that low-level flow or configuration as the advanced tooling has supplanted them. The same can be said for the other elements of API-Management. 

From a business driver perspective we can see how this 'enablement' is shifting specification items closer to the hands of people who are more focussed on the high-level purpose of the specification and away from the low-level implementation. This is good - APIs help maintain the purpose of the business specification right through to implementation. 

Although architectural best practice is rarely touted as an API benefit - it is (in my head at least ;-) a biggie. Gaining and maintaining clear governance over your services is very important and APIs just made it a lot easier.

Monetisation

Monetisation is always touted in terms of direct money making from the API. Whether that be someone making money from selling their API or someone making money from using third party, potentially free, APIs. This is old ground and I'm not too concerned about travelling it again here. 

Enough to say that the more exciting examples often discussed are the companies who don't own any assets. These companies just use other people's APIs and make cool new companies from them - think Uber or Just Eat.

Clearly, these guys are smart at aggregating other people's data and using it. However, I also describe this as 'best person for the job'. I've noted over the years  that quite often the coolest app is not done by the company who owns the data.

Indeed, why should any company believe that it's got the best app developers in the country or world when all it has to do is expose and potentially sell its API  and see who is the best.

Regulation

PHIN, OBWG, ONC, HL7 - ever heard of them ? These are some of the organisations and protocols that are being affected by or are affecting regulation. I'll summarise these below...

PHIN: Private Health Care Information Network

This is an independent UK based organisation which has a mandate ( Private Healthcare Market Investigation Order 2014.) given to it by the Competition and Markets Authority (CMA). This mandate was based on the on-going (at time of writing) investigation by the CMA into the private healthcare market in the UK. It found that the lack of clear performance and fees data coming out of the private health care providers was 'harming customers'. To this end the CMA have ruled that the private healthcare providers make the relevant data public and that PHIN shall act as the central repository of that data.

OBWG: Open Banking Working Group

In the 2015 UK Budget HM Treasury announced its commitment to delivering an open standard for  APIs in UK banking. This will help customers have more control over their data and make it easier for financial technology companies (FinTechs) or other businesses to make use of bank data on behalf of customers in a variety of helpful and innovative ways. The government explained that this would help drive more competition in banking and improve outcomes for customers. It will also further support the UKs world leading FinTech industry.

The OBWG was established in the summer of 2015 to achieve just that. Their mission is define a framework for how those APIs could be designed and created along with a timetable for implementation.

Essentially this means that over the next few years UK banks will have to allow access to all but their most proprietary data. Customers (you and me) will be able say who is allowed access to that data e.g. particular mobile apps for instance.

Interestingly, these UK specific regulations are over and above a new set of regulations which are currently being thought through by the European parliament. The European Parliament is also considering how to open up customer banking data to the wider-market. The UK's stance over being bigger and better is quite deliberate. The UK government wants the UK to be innovating faster than its European competitors in the "API economy" !

ONC: Office Of the National Coordinator

In the U.S. the ONC are pushing for the same sort of Health-care openness as they are seeing across the pond. Although not as clearly developed as the UK or European initiatives it's obvious that the ONC want the U.S. Healthcare organisations to embrace a more API led data model. This has quite profound implications for the providers and their current applications.  

The current state of the nation is a very push led model where the data being exposed is wrapped up in potentially very technical documents. In order to allow more pull like API models this data needs to be teased apart. The definitions of those API's and the data they contain could be a massive job.

Note:  It appears that, for various reasons, the health-care providers are pushing back on the API economy. As I don't want to get into political debates in this entry, I'll leave that sentence hanging ;-)

HL7

HL7 is a globally well-known  health care protocol. It allows just the sort of data that I mentioned above that the ONC is trying to split out into APIs. For instance, if you were a doctor seeing a patient for the first time in a hospital you may well be able to receive the records of the incident you are seeing your patient about through the underlying use of HL7. 

As I'm sure you can imagine, under-the-hood this protocol is not user-friendly - having being designed for expediency of network and storage usage - not human readability.

To this end, the healthcare IT industry could well be in the business of splitting out those HL7 records into more manageable API call resources.

Australian Government

Today I learnt that the Australian government is doing a sweeping review of how to expose public and private datasets. They say they want to do this in order to maintain innovation. This is just yet another indicator of how the world is changing into an API led economy.

Conclusions

I've shown how there are several motivations for providing API's. Direct monetisation of internal assets is just one of those reasons. In terms of general good IT practice APIs can be seen as an excellent way to achieve governance of your systems and move the initial specification closer to the implementer. 

Straight monetisation of your assets is clearly still an obvious motivator for many companies. However, there is a global shift whereby companies are being forced to expose their data assets in order to enable competition. This is happening from Healthcare to Banking and beyond.