“Cracking the code of how to best implement and monetize APIs is crucial to success in the emerging API economy.”
Part 5 – The Planet of the APIs
After a brief holiday hiatus, we’re back to inspect the multiple aspects of the transformation that is taking all aspects of information technology from a traditional private do-it-yourself isolated model to a modern public outsourced cooperative model. These aspects, or threads as I have been calling them, have led us to a place where they, in combination, have propelled IT beyond a line of demarcation between the old and new ways of doing things. Here again is the overview graphic I’ve been using to guide our exploration, with today’s focus being on the API Economy.
We started our tour in the lower left of the above diagram, talking about the composability of hardware and software systems, followed by the cloud model that has been realized through achievements in software defined networking, and more recently in applying lightweight virtualization to achieve uniform packaging and distribution of workloads. These are all “nuts and bolts” things – the gears inside the big machine that give us capabilities. But capabilities to do what, exactly? What problems do they help us solve, and in what ways are those solutions superior to the ones that came before?
Throughout our discussion, the terms dynamic, reusable, shared, distributed, and lightweight have appeared consistently and repeatedly. Clearly, the difference between this “new” way of doing IT and the “old” way of doing it includes these characteristics, and they are present not only at the lower level where the technology components reside, but also in the higher levels of the stack where those technologies are harnessed to solve business problems. This is where the “API Economy” thread enters the discussion, because it is concerned with how we use these new building blocks to achieve better outcomes in problem solving – specifically in enabling organizations to do business on the Internet.
Application Programming Interfaces, as with most of the other things on the big wheel above, are not new. However, when combined with recent strides and innovations in connectivity technologies, they become a focal point in the ongoing transformation. Decades of work have gone into understanding how to build complex software systems. A key tenet of enterprise software design is to decompose a problem into smaller sub-problems, then solve those sub-problems in a way that their respective solutions can be later combined to solve the larger problem. This also allows us the opportunity to identify code that can be shared across the same solution. For example, if we need to sort several tables of numbers, we write the sorting code only once, and design the solution to call that code with different tables as needed. This “divide and conquer” method is shown at the far left of the figure below.
But a valuable consequence of this approach is the creation of code that can be shared outside of the initial solution for which it was conceived. If we create an online catalog for a book store as part of its overall IT system, we can likely reuse that component for a grocery store, provided we built the component with re-use in mind. Historically, such components are kept in libraries of either source or object code that can be distributed and shared between developers that later compile or link them into larger solutions as needed, as shown in the middle of the figure above. This is only possible if the entry points into the reusable code module are well documented, and the module itself has been designed with easy re-use in mind. APIs help in both of these matters, by providing consistent, well documented entry points (typically, subroutine invocations) and ensuring that the module is self-sufficient (isolated), relying only on the information it receives through its API to set client-specific contexts.
This method of sharing, which is essentially the copy/paste model, is not very efficient. When changes are made to the master source code for the shared component, the changes must be propagated to all instances of the component. For traditional digital media, this is extremely cumbersome. Online repositories improve the experience somewhat. Still, it is a matter of transporting and updating code instead of transporting and operating on data.
Until recently, this was the best we could hope for, but with the high-speed ubiquitous Internet, and with universally adopted standards such as the Hypertext Transport Protocol (HTTP) to carry API payloads, we finally have achieved more dynamic and lightweight means of sharing code as shown in the far right of the figure above. Instead of copying and replicating the code, we extend Internet access to running instances of it. Changes to the code can be rolled into the service and instantly be in use without users of it needing to make updates. API management is also evolving to assume this model of reuse: By assigning version control to the API itself, we can evolve the service over time while ensuring that clients always connect to a version that offers the features and semantic behaviors they are expecting.
So that’s the “how” part of it. But “why” is this important?
The new use cases we will discuss at the conclusion of this series are born of opportunity brought about by global hyper-connectivity, device mobility, and large-scale distribution of data. Big Data Analytics, the Internet of Things, taking full advantage of social media, and similar cases require that we be able to connect data to processes within fractions of a second, regardless of their locations. To be competitive in this environment, and certainly to take advantage of its opportunities, businesses must be able to “hook in” to the data stream in order to provide their own unique added value. APIs, and the services backing them, are the technical mechanism for achieving this. Any organization wishing to participate in the emerging API economy, where data is the currency, and the ability to transport and transform that currency into ever more valuable forms, must have a well-defined, easy-to-use API with a dependable, scalable service behind it. This becomes a building block that developers can acquire in building their applications, which gives the vendor behind the API more clout and relevance in the ecosystem.
Although the technology for creating and managing these APIs and services is largely ready, there is still much experimentation to be performed regarding how to extract revenue from these constructs. The easiest to understand is basic pay-for-access; but, in a world where most services are “free”, potential customers will likely be offended to be charged just to walk through the front door of an API, so we have variants of limited use with paid upgrade, trial periods, personal data as payment, and so on.
Although Darwinian-type evolution was not the cause of apes ascending to dominate the Earth in “The Planet of the Apes” (it was a bootstrap paradox, for those who really worry about such details), their ascendance was still due to mankind’s inability to evolve to meet the threats and capitalize on the opportunities that a changing environment presented. Cracking the code of how to best implement and monetize APIs is crucial to success in the emerging API economy. We still don’t know which variations will prove to be the dominant species of API interaction models. Only one thing is certain: those who wait to find out won’t be around to benefit from the knowledge: They will be extinct.
