The world has changed. Information technology has changed every aspect of our lives: from fundamental things, such as how we purchase goods, interact with brands, and even do our jobs, to how we communicate with each other. In fact, a study by British psychologists suggests that around two billion people use smartphones across the globe, with over half the population in developed countries relying on them on a daily basis. That's over half a billion people worldwide using their phones to do all sorts of things, 85 times on average each day, according to the same study.

However, the aforementioned study only focuses on smartphone usage. If you factor in interactions with other devices, such as tablets, personal computers, wearables, and even machines (that is, smart cars and voice assistants such as Alexa), the number of interactions is huge.

For a start, it is pushing the boundaries of what we thought was possible and making science fiction seem real. Most importantly, it has opened up new avenues for businesses to innovate and disrupt the market, which is exactly what the so-called "digital disruptors," such as Google, Apple, Facebook, Amazon, and Netflix, in fact did, and continue to do. Established businesses, such as Blockbuster and Kodak, couldn't cope with the (digital) innovation introduced by Netflix and Apple, and ended up filing for bankruptcy. Traditional industries, such as the taxi industry and hospitality, are also being severely disrupted by Uber and Airbnb.

These companies are just the obvious examples that everyone talks about. With over 100 million new start up businesses launched every year, even if only 10% (as analysts predict) are successful, we are talking about 10 million new companies with the potential to become the new Netflix or Uber, but for different industries.

Now, because of this, it's no wonder that most organizations globally have embarked on digital transformation initiatives in order to avoid being (further) disrupted. As Harvard Business Review (HBR) nicely put it:

According to the same article by HBR, the most disrupted industries are those that relate to Business to Consumer (B2C), with media and telecom at the top of the list, closely followed by financial services and retail:

However, these figures should not come as a surprise. A closer look shows that there is a direct correlation between the disrupted B2C organizations and the fact that 2 billion individuals are using their smartphones and other devices frequently. Put simply, B2C organizations that haven't been able to innovate and engage customers in different ways, and through digital channels, are more susceptible to being disrupted by newer and more agile businesses:

These organizations that are more exposed to digital disruption are therefore faced with a dilemma. In order to remain relevant and stay in business, they must create a digital strategy that allows the business to innovate and be more agile. However, in order to do so, they can't simply get rid of old systems of record, most of which are legacy and contain critical information assets that support day-to day-operations.

Bearing in mind that most of these organizations can't afford to start from a white sheet of paper, the digital strategy must therefore cater to the transformation of hundreds (if not thousands) of existing systems, many of which are considered legacy.

Such an undertaking can be huge, not only in terms of costs to the business, but also in terms of the risks. This is exactly where the dilemma lies: do nothing and save costs/avoid risks, and most likely end up being disrupted, or become a disruptor by taking the business on a digital transformation journey, which could be risky and costly.

Is it really that risky and costly to take the business on a digital transformation journey? Well, as with everything, it depends. Organizations that perceive digital transformation as merely an exercise to adopt omnichannel strategies, without first understanding "why" they are doing it, or "what" they are trying to accomplish, will most likely fail to realize any business benefits. For these organizations, such an undertaking will have plenty of unknowns and will therefore be perceived as risky and costly.

Organizations that start off with the creation of a digital strategy to articulate the targeted business goals, and also identify what business and technical capabilities are required in order to achieve this, will most likely perceive the digital journey as a key enabler for the business strategy, rather than just another expensive IT project. For such organizations, digital transformation represents a justifiable and calculated risk.

It's no wonder that Forbes listed digital transformation as the #1 priority for Chief Information Officer's (CIO) in 2017:

However, in order to achieve this, the devil is in the detail. The "how" question should not be forgotten and must be thoroughly addressed while defining the strategy. For example, one of the biggest challenges faced by organizations undertaking digital transformation is around how to get access to core enterprise information assets, most of which are typically locked in hundreds of systems of record. Therefore, without unrestricted, secured, and reliable access to such systems, introducing any sort of innovation will be nothing more than a prototyping exercise.

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.

With an increased number of public and internally developed APIs offering a wide range of functionality (that is, access to Software as a Service (SaaS applications), bank transactions, artificial intelligence, and address services, to name a few), it can be quite tempting for developers to quickly incorporate the use of all sorts of APIs within their applications.

However, doing so in an uncontrolled manner can, and will most likely, result in what some call a hyperconnectivity mess. This is when IT systems are interconnected and dependent on APIs, but no one within the enterprise really has visibility and/or understanding of this. Not only can this result in a serious gap in accountability when issues occur, but, in an even more complex IT landscape, systems can have real exposure to issues outside of the control of enterprise IT.

This is the reason that the management of APIs has become so critical, and this does not just apply to the APIs being internally developed within enterprise IT, but also to the use of public APIs within enterprise systems.

API management, therefore, is born as a discipline to manage APIs (both internal and external), meaning establishing the processes, roles, and responsibilities, and the tools required to govern APIs throughout their full life cycle.

Any API management initiative should focus on at least the following aspects of the life cycle:

1. Planning: Provides the required facilities (tools) to plan in advance for the creation and/or modification of APIs. Regardless of the methodology used to deliver the APIs or whether there is one or multiple teams implementing it, there should be a common approach, and ideally tooling to capture which APIs are the priority, and who is responsible for delivering them. This is important as it will provide visibility to any relevant party of the capabilities being delivered, and therefore encourage coordination/collaboration over the duplication of work. The tools used to ensure tracking/status of the teams implementing APIs should also be addressed.
2. Design: Design-first thinking is fundamental in any API management initiative. Tools and processes that enable API-first design (covered in detail in subsequent chapters), and that encourage API designers and API consumers to interact during the design of an API, will shorten the development life cycle and therefore reduce costs, as the actual product produced will most likely meet the requirements from the get-go, without having to iterate several times through the entire implementation process to get it right.

• An important consideration during the design phase is around what level of security controls are to be adopted in the API. Authentication and authorization, for example, should not be an afterthought, as they will have considerable impact on API usability. Therefore, rather than doing this later in the life cycle, security should also be part of the API design.

3. Implementation: The actual implementation of the APIs requires adequate processes and tools to be in place, such that developers can focus their efforts on producing actual code and not on sorting out life cycle concerns, such as code coverage, continuous integration, regression testing, and deployment. For this reason, automating and streamlining the implementation cycle of the API, by creating development pipelines that make it very easy for developers to move code from development all the way to production, will deliver considerable results for the business.

• It's worth highlighting that development pipelines do not mean bypassing quality gates. It is still possible, in fact recommended, to also introduce quality gates. However, if the same can be automated (that is, verifying that the results of code coverage and regression testing are adequate), quality assurance can still be introduced, but without the burden and costs of manually testing the API.

4. Publication: Making APIs discoverable is fundamental in API management. Providing the facilities to easily deploy and version APIs, but most importantly to publish them along their relevant (consumer-oriented) documentation in a developer portal, ensures that developers can reuse APIs, rather than reinventing wheels, and ultimately reduces development and operations costs.
5. Operation: Runtime operations is as much about "keeping the lights on" as it is about providing meaningful analytical insight to both the business and IT, so they, too, can make the most out of the operational data being generated. From simple capabilities, such as central operations, API statistics, gateway stats, user management, and system management, to more sophisticated ones, such as application performance monitoring (APM), SLA management, rule-based alerting, predictive analytics, self-healing, and API metering, operations is, without a doubt, a first-class citizen in API management.
6. Consumption: API management is not just about designing and building APIs, but also about consuming them. With the number of public APIs growing exponentially, the expectation is that some organizations will be consuming more public APIs than they will end up building them. The problem is that without proper controls and visibility over who by/why/which/when public APIs are being used and the associated costs, organizations can easily end up in the hyperconnectivity mess described previously. To prevent this pitfall, API management must equally focus on providing the means and facilities for public APIs to be consumed in a controlled and governed manner. In other words, developer portals should not only allow for internally developed APIs to be published, but also external ones.
7. Maintenance: In API management, the life cycle doesn't end when an API goes live. In fact, it only gets started. As it will be better described in the next section, APIs should be treated as products and, as such, the product must be continuously evolved by taking into account evolving consumer needs and expectations. For an API to become a good product, it must undertake a series of iterations and changes. API management should therefore make it easier to do so.

8. Retirement: When an API has served its purpose and there is a need to decommission it, it should not be the case that doing so is complex and cumbersome. API management should also take care of the process and capabilities needed to retire an API and handle (minimize) the impact that this may cause to any existing consumers.
9. Community management: As previously described, APIs also open the door to new digital ecosystems. In such ecosystems, the main actor is the developer. With thousands of developers worldwide, managing communities of internal (known) developers, partner developers, and external (unknown) developers is another fundamental aspect of API management. Self-service facilities for development onboarding and developer portals, whereby developers can search for APIs, subscribe to them, read their documentation and even comment and rate them, are some of the capabilities that API management should offer.

Realizing the benefits that APIs have to offer to a business can't be completed in a day, and organizations that think that monetizing their information assets will be a simple and straightforward exercise are going to be in for a surprise. Rome wasn't built in a day, or so it goes.

Like most things, there is always a journey and a path that, when followed, will guide us toward getting to an end goal or a target. It will not necessarily be quick, as that pretty much depends on the pace an organization can deliver, but at least there will be the certainty of avoiding common pitfalls. That is not to say that some organizations might not opt for a different (and perhaps shorter) path.

That said, the following API value chain illustrates both a path and a maturity model to help organizations of all sizes to embark on the journey of API management maturity:

The value chain classifies APIs into five main groups. Each group is determined based on the business value it adds, which, in turn, also dictates maturity according to this business-led model:

Businesses that want to realize the full business benefits that APIs have to offer, for example, as part of their digital transformation initiatives, should first consider what would be their entry point and, based on that, determine a roadmap to get to the next levels. Details on how to define such a roadmap are described in Chapter 3, Business-Led API Strategy.

The value and potential that APIs bring to a business haven't gone unnoticed. Many of the largest software vendors worldwide have made considerable investments to strengthen their API management portfolios in a relatively short period of time. In less than three years, six major acquisitions have taken place:

1. TIBCO acquired Mashery from Intel, which was perhaps expected, as TIBCO, a well-known player in the integration space, did not really have a strong (or at least popular) API pure-play capability.
2. Red Hat acquired 3scale, which was expected to an extent, as the move was perceived as complementary to Red Hat's Fuse and OpenShift offering, the latter also a recent acquisition.
3. Next was the very surprising acquisition of Apigee by Google, which was considered by many as a sound and strategic move by Google to more rapidly penetrate the enterprise cloud software market.
4. More recent acquisitions started with Oracle acquiring the API-design pure-play Apiary, a move also considered interesting and strategic, as Oracle had been investing, and continues to invest, heavily in strengthening its Platform as a Service (PaaS) offering.
5. The Salesforce.com acquisition of MuleSoft was also broadly expected, as both companies had enjoyed a strong partnership for a few years and the MuleSoft Anypoint offering is also seen as complementary to the Force.com platform.
6. Most recently (at least at the time this chapter was written), there was the highly unexpected acquisition of CA Technologies (also a leader in the API space) by Broadcom, which is traditionally a semi-conductor manufacturer.

So, what can be deduced from all of these acquisitions? First of all, of the six acquirers mentioned, three are actually major players in the enterprise cloud space. Therefore, their investment in the API space can be seen as a move to strengthen their PaaS portfolios, which is a multi-billion dollar market on its own. Furthermore, when it comes to cloud, APIs are considered the main means to get access to information and functionality electronically, so offering strong API management capability as part of an SaaS, PaaS, or even Infrastructure as a Service (IaaS) offering is a clear value add.

Secondly, the acquisitions made by TIBCO, Red Hat, and perhaps even Oracle, can be seen as an indication that the integration market is shifting and that more traditional integration capabilities (traditionally based on large-footprint integration middleware backboxes) are being superseded by API-led architectures, where the integration middleware is either very thin or non-existent (as is the case in Microservices Architectures, where event-driven interoperability is favored).

Lastly, although the acquisition by Broadcom was highly unexpected, the market is no stranger to such moves. The purchase is, in fact, comparable to the one made by Intel in 2013, when Mashery was acquired, in theory to strengthen Intel's play in the IoT. However, it's questionable whether the move paid off, as Intel soon after sold Mashery to TIBCO.

However, this last acquisition raises an important point: APIs being an enabler for the IoT. As devices and machines of all sorts, from wearables, to home appliances, vehicles and industrial machines, to name a few, all become smarter and more capable of storing and processing data, the need and demand to access information in real time can only increase. This means that APIs will also (if not already) be implemented to enable IoT. For companies such as Broadcom, and/or many others in the manufacturing/industrial space, this represents a huge opportunity, as they'll be able to expand their existing offerings to also offer digital services (for example, real-time monitoring and alerting, remote and real-time management of infrastructure, predictive maintenance and analytics, to name a few).

This chapter delivered a comprehensive and business-oriented explanation on the value of APIs, and the reasons why they are a must in any digital strategy.

The chapter started by describing why and how digital disruptors are taking the industry by surprise, and the impact this is having on more established and traditional organizations, many of which are struggling to cope with the pace of change, and the level of innovations being introduced.

To this end, the chapter explained the true meaning of disruption and why understanding it is extremely important for successfully creating a digital strategy, and then embarking on a digital transformation journey.

In this same context, it was highlighted that gaining real-time access to an organization's enterprise information assets (many of which are locked in legacy systems) holds the key to success and, without this, a digital strategy's chances of success will be minimal.

The chapter continued by describing and positioning APIs as the means to deliver such access, and thus act as an enabler to digital strategies. It was described in great detail how APIs can add value to a business, for example, by allowing the business to monetize information assets, comply with new regulations, and also enable innovation by simply providing access to business capabilities previously locked in old systems.

Subsequently, an API value chain was introduced, illustrating a business-centric API maturity model suitable for use as reference when embarking on an API implementation initiative.

The chapter concluded by describing how the software industry is reacting as some of the largest software vendors in the world make major acquisitions in the API space.

In the next chapter, a more technical point of view will be described, which explains how and why the technologies and platforms used to implement APIs have evolved from simple web proxies to third-generation API platforms.