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.
Figure 1.10: Hyperconnectivity can also create an ad hoc mess
A hyperconnectivity mess occurs as a result of APIs being used in an ad hoc manner and without proper governance. At this point, the business benefits that APIs have to offer can be countered by the risks they can introduce to core enterprise systems, and thus business operations themselves.
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.
Figure 1.11: API management
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.
API management differs from related disciplines, most notably SOA governance, in that it is much more lightweight and a lot more focused on making the lives of the API consumers (developers) easier, by providing the right tools for the design and run aspects of APIs, and making processes simple to follow. SOA governance, on the other hand, is fine-grained, with detailed processes and complex tools. Chapter 2, The Evolution of API Platforms, covers this in more detail.
Any API management initiative should focus on at least the following aspects of the life cycle:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
