Are APIs a legal requirement in your industry today? The answer for now is â€śnoâ€ť. But donâ€™t relax thinking you do not need to act, this answer will very quickly be changing to â€śyesâ€ť. It is already starting in some industries and geographies and more will follow. APIs being a simple and secure manner to communicate information are a logical progression from the more complicated regulatory required interfaces that have existed in the past.
My point here is not to explain PSD2, the prior two links do a very good job of this. The point is that PSD2 is a legal requirement that Banks need to meet in the EU requiring the use of APIs. PSD2 is still being finalized, but a target date is set for roll out in late 2017.
In the USA Healthcare industry new rules are being established to promote the use of APIs in accessing patient health related information. The rule itself is 752 pages long, so I wonâ€™t be describing the details here. However, it is summarized very nicely in this article, â€śA Brief Summary of the CMS Meaningful Use Final Ruleâ€ť. The rule is still in the comment period, but the current schedule makes APIs optional in 2017 and required in 2018. The author argues that rather than regulate the inclusion of APIs, an incentive approach should be used. Regardless of which occurs, APIs are coming to Healthcare.
So, what about industry standards? We are about to see this start and should progress rapidly. Unlike regulatory change pushing API usage I expect a natural pull toward industry standards. API industry standards are simply beneficial to all the participants, so there should be little to get in the way. Iâ€™ll explain.
Letâ€™s start by referencing back to an early blog I wrote on API Economy Drivers. In this I focused on two primary drivers â€“ Speed and Reach. For this discussion on standards I want to focus on Reach. Reach is about making APIs available external to your business (to partners or public) to drive additional revenue by expanding to new channels. The case for industry standards is about interactions between businesses in your industry or businesses dealing with your industry. Take a look at sample use cases in your industry (API Use Cases for Every? Industry) related to partner or public interactions to get some idea about the type of interactions that might become standardized.
First letâ€™s look at sharing APIs from the API provider perspective. It is certainly preferable to provide one API for a particular purpose that is used by many partners (API consumers) than to provide many. Creating individual custom APIs based on the needs of individual consumers would be more costly from a Devops perspective. Looking at API sharing from the other side (API Consumer), the consumer does not want to have to invoke differently behaving APIs from each provider offering the same information. It would be much less costly to the consumer if the APIs all had the same structure and returned similar data.
Here are some examples to illustrate this:
- In many industries third parties are writing comparison Apps that look across businesses in the industry.Â Examples include Travel
where comparison Apps search across airline, hotel, and car rental options, Banking/Finance comparison Apps â€“ perhaps comparing loan rates, and retail shopping â€“ searching across retailers for the best option to purchase a product. In each of these, the comparison Apps (and there may be several) are the API consumers and the businesses offering the products or services are the API providers. As an API provider I want to supply one API that all the comparison Apps can use to find my offerings. The comparison App would like to have consistent API behavior provided by each provider so that they can invoke each in a similar manner and receive similar response formats. To the extent that any of these are different, companies that donâ€™t conform cause extra effort and potentially might not be included in the comparison.
- I did some work with a company in the Financial Services industry who came to their own conclusion that API standards would be beneficial. In this industry there are many companies that provide financial offerings (e.g. mutual funds, annuities, etc.) and also many companies that have a relationship with customers selling the financial offerings from many providers. This company recognized a need in the industry to standardize the communication between the industry participants and asked IBM to help facilitate a session with their partners that sell their offerings and also include their competitors who sell competing financial offerings. Â Â Â They recognized that for this to be successful the industry would need to adopt these standards. It could not be driven by an individual partnership arrangement.
Whether it is through regulatory requirements or businesses working together in an industry, we should expect that industries will come together on common API standards. I believe this will happen primarily because it is benefits all the participants. Consider this my prediction, but I am feeling pretty confident this will happen. No doubt industries will move at different paces, but we can see that this is already starting in several industries and geographies.
Having standards for APIs does not do away with the need for APIs to be managed. To achieve success you should always put controls around the APIs so that you know who uses the APIs and how much and can map this to the results. With this visibility, you can use analytics to determine which techniques are working and which are not.
One last comment on a slightly different but related topic. IBMs Interconnect 2016 Conference is quickly approaching: Feb 21 â€“ 25 in Las Vegas. The API Economy and API Management are major parts of the conference agenda. This is a great opportunity to talk to your peers at other companies to find out what they are doing, hear great presentations, ask questions at panel discussions, and explore new technologies at the Expo. I will be there and look forward to meeting you and discussing what you can do with APIs at your company.