APIs are like doors that provide access to information and functionality to other systems and/or applications. APIs share many of the same characteristics as doors:

• Most of them have locks and, without the key, they can't be opened.
• They come in different types (size, color, material, type of lock, and so on).
• They can serve different purposes. For example, they can be public-facing or just internally accessed.
• They are located in a specific location: an address.
• They can be as secure and closely monitored as required.
• If they don't work, it will affect the experience of their users.

APIs, however, are not new. In fact, the concept goes back a long time and has been present since the early days of distributed computing (some argue even before then). However, the term as we know it today refers to a much more modern type of API, known as REST or Web APIs.

Modern APIs started to gain real popularity when, in the same year of their inception, eBay launched its first public API as part of its eBay Developers Program. eBay's view was that by making the most of its website functionality and information also accessible via a public API, it would not only attract, but also encourage communities of developers worldwide to innovate, by creating solutions using the API. From a business perspective, this meant that eBay became a platform for developers to innovate on and, in turn, eBay would benefit from having new users that perhaps it couldn't have reached before.

eBay was not wrong. In the years that followed, thousands of organizations worldwide, including known brands, such as Salesforce.com, Google, Twitter, Facebook, Amazon, Netflix, and many others, adopted similar strategies. In fact, according to programmableweb.com (a well-known public API catalogue), the number of publicly available APIs has been growing exponentially, reaching over 20k as of August 2018:

It may not sound like much, but considering that each of the listed APIs represents a door to an organization's digital offerings, then we're talking about thousands of organizations worldwide that have already opened their doors to new digital ecosystems, where APIs have become the products these organizations sell and developers have become the buyers of them.

In such digital ecosystems, communities of internal, partner, or external developers can rapidly innovate by simply consuming these APIs to do all sorts of things: from offering hotel/flight booking services by using the Expedia API, to providing educational solutions that make sense of the space data available through the NASA API.

There are ecosystems where business partners can easily engage in business-to-business transactions, either to resell goods or purchase them, electronically and without having to spend on Electronic Data Interchange (EDI) infrastructure. Ecosystems where an organization's internal digital teams can easily innovate as key enterprise information assets are already accessible.

So, why should businesses care about all this? There is, in fact, not one answer, but multiple answers, as described in the subsequent sections.

What is innovation? According to a common definition, innovation is the process of translating an idea or invention into a good or service that creates value, or for which customers will pay. In the context of businesses, according to an article by HBR, innovation manifests itself in two ways:

• Disruptive innovation: Described as the process whereby a smaller company with fewer resources is able to successfully challenge established incumbent businesses.
• Sustaining innovation: When established businesses (incumbents) improve their goods and services in the eyes of existing customers. These improvements can be incremental advances or major breakthroughs, but they all enable firms to sell more products to their most profitable customers.

• Further reading: What is disruptive innovation?
  https://hbr.org/2015/12/what-is-disruptive-innovation
  

Why is this relevant? It is well known that established businesses struggle with disruptive innovation. The Netflix versus Blockbuster example reminds us of this fact. By the time disruptors are able to catch up with an incumbent's portfolio of goods and services, they are able to do so with lower prices, better business models, lower operating costs, and far more agility and speed to introduce new or enhanced features. At this point, sustaining innovation is not good enough to respond to the challenge.

With all the recent advances in technology and the internet, the rate at which disruptive innovation is challenging incumbents has only grown exponentially. Therefore, in order for established businesses to endure the challenge put upon them, they most somehow also become disruptors. The same HBR article describes a point of view on how to achieve this from a business standpoint. From a technology standpoint, however, unless the several systems that underpin a business are "enabled" to deliver such disruption, no matter what is done from a business standpoint, this exercise will likely fail.

Perhaps by mere coincidence, or by true acknowledgment of the aforesaid, Gartner introduced the concept of bimodal IT in December 2013, and this concept is now mainstream.

Gartner defined bimodal IT as the following:

According to Gartner, Mode 1 (or slow) IT organizations focus on delivering core IT services on top of more traditional and hard-to-change systems of record, which, in principle, are changed and improved in longer cycles, and are usually managed with long-term waterfall project mechanisms. Whereas, for Mode 2 (or fast) IT organizations, the main focus is to deliver agility and speed, and therefore they act more like a start-up (or digital disruptor in HBR terms) inside the same enterprise.

However, what is often misunderstood is how fast IT organizations can disruptively innovate, when most of the information assets, which are critical to bringing context to any innovation, reside in backend systems, and any sort of access has to be delivered by the slowest IT sibling. This dilemma means that the speed of innovation is constrained to the speed by which the relevant access to core information assets can be delivered.

As the saying goes, "Where there's a will, there's a way." APIs could be implemented as a means for the fast IT to access core information assets and functionality, without the intervention of the slow IT. By using APIs to decouple the fast IT from the slow IT, innovation can occur more easily.

However, as with everything, it is easier said than done. In order to achieve such organizational decoupling using APIs, organizations should first build an understanding about what information assets and business capabilities are to be exposed as APIs, so the fast IT can consume them as required.

This understanding must also articulate the priorities of when different assets are required and by whom, so the creation of APIs can be properly planned for and delivered.

Luckily, for those organizations that already have mature service-oriented architectures (SOA), some of this work will probably already be in place. For organizations without such luck, this activity should be planned for and should be a fundamental component of the digital strategy.

Then, the remaining question would be: which team is responsible for defining and implementing such APIs; the fast IT or the slow IT? Although the long answer to this question is addressed throughout the different chapters of this book, the short answer is neither and both. It requires a multi-disciplinary team of people, with the right technology capabilities available to them, so they can incrementally API-enable the existing technology landscape, based on business-driven priorities.

Many experts in the industry concur that an organization's most important asset is its information. In fact, a recent study by Massachusetts Institute of Technology (MIT) suggests that data is the single most important asset for organizations:

If APIs act as doors to such assets, then APIs also provide businesses with an opportunity to monetize them. In fact, some organizations are already doing so. According to another article by HBR, 50% of the revenue that Salesforce.com generates comes from APIs, while eBay generates about 60% of its revenue through its API. This is perhaps not such a huge surprise, given that both of these organizations were pioneers of the API economy.

What's even more surprising is the case of Expedia. According to the same article, 90% of Expedia's revenue is generated via APIs. This is really interesting, as it basically means that Expedia's main business is to indirectly sell electronic travel services via its public API.

However, it's not all that easy. According to the previous study by MIT, most of the CEOs for Fortune 500 companies don't yet fully acknowledge the value of APIs. An intrinsic reason for this could be the lack of understanding and visibility over how data is currently being (or not being) used. Assets that sit hidden on systems of record, only being accessed via traditional integration platforms, will not, in most cases, give insight to the business on how information is being used, and the business value it adds. APIs, on the other hand, are better suited to providing insight about how/by who/when/why information is being accessed, therefore giving the business the ability to make better use of information to, for example, determine which assets have better capital potential.

Another challenge that is increasingly being faced by organizations concerns compliance and regulation. Let's take, for example, the introduction of the General Data Protection Regulation (GDPR), which, as of May 2018, regulates how organizations worldwide are expected to handle the customer data of European Union (EU) citizens, with the risk of being exposed to eye-watering fines. Similarly, the second payment service directive by the EU, otherwise known as PSD, has introduced important regulations to open up core banking transactions and information.

Superseding the EU Data Protection Directive, GDPR has the objective to give individuals (EU citizens) more control, protection, and privacy over how their personal information is used and by whom.

With personal data being at the heart of GDPR, how can APIs help with complying with the GDPR regulation? Although APIs may not be the only answer, a good API management solution will introduce strong access control over who can access what information via APIs, therefore ensuring that personal data is not misused or accessed without prior consent. In addition to these controls, the solution should also provide full visibility and auditability over data access, meaning that any data breach can be notified to customers and authorities as soon as possible, or within the 72-hour period, as indicated in the regulation.

PSD2 aims to stop financial institutions' monopoly over the use of customer data and payment services.

By the end of 2018 (when the directive first came into effect), financials institutions in the EU should have opened the doors of their customers' data and payment services to third-party providers.

In practical terms, what this means is that in the near future, you might be using Facebook, for example, to check bank account balances, do bank transfers, and pay bills.

Another example, in the same industry, is the Open Banking initiative being introduced in the United Kingdom as a result of the Retail Banking Market Investigation report produced by the Competition and Markets Authority (CMA). In a nutshell, the initiative aims to promote increased competition and consumer choices in the banking industry by forcing banks to securely share their data via an Open Banking API.

However, this is easier said than done. According to research, over 75% of financial institutions in Europe still run on outdated systems. Worldwide, the figure is similar, if not more.

Bearing in mind that making changes to these systems won't be a trivial task, the expectation is that software vendors and system integrators alike will come up with pre-built solutions, which will make the process of creating APIs on top of systems and complying with regulations, such as PSD2 and CMA Open Banking, a lot easier.

It is not just the financial industry that's embracing the use of APIs. In healthcare, for example, a newer version of the widely adopted health-level 7 (HL7) international standard, known as the Fast Healthcare Interoperability Resources, or FHIR (pronounced "fire"), defines, in fact, a REST API.

In the USA, for example, the healthcare industry is this a step further and introducing a rule to promote the use of standard APIs to access patient records.

Although it is still very early days, the expectation is that this trend will continue, and that more regulation will be introduced that promotes the use of APIs as the means to provide open access to information and enable interoperability.

Just as is the case in traditional SOA, whereby one of the key principles is to build reusable web services and not just to avoid duplication of functionality, but also to reduce development costs, in the case of web APIs, the same principle can apply.

It is possible, and, in fact, recommended, that business APIs are created internally, so business functionality that needs to be commonly accessed is then made available as an API. This will not only allow such functionality to be accessed in real time and in a standard, controlled, and secure way, but it is also a much better alternative to data replication techniques that risk losing visibility and control over who by/why/when/how information is being accessed.

By creating a common business API layer, not only does innovation and bimodal IT become possible (as described previously), but other business benefits can be realized, such as lower development costs by reusing already available APIs, reduced duplication of system functionality, and increased visibility and analytics around the usage of data, which can provide the business with meaningful business insights.