Keeping API Entropy Low is Needed to Continue API Growth and Expansion

I love the word entropy. It means so many things to so many different people. In means different things in the physical realm versus the informational or virtual realms. It is one of those big words you can say to confuse people, or actually get yourself in trouble being able to actually defend your position on what entropy means when around smart people. It is said that famed mathematician John Von Neumann had told fellow mathematician and creator of Information Theory that he should use the word entropy instead of information because that no one understands entropy and then you can win arguments about your theory. I also read that Shannon and Norbert Weiner also dueled over the meaning, seeing it in very opposite ways. I like the word for all of these reasons, but mostly because of its relationship to uncertainty. 

In the realm of physics entropy means, a thermodynamic quantity representing the unavailability of a system's thermal energy for conversion into mechanical work, often interpreted as the degree of disorder or randomness in the system In the more virtual realm of information theory, the entropy of a random variable is the average level of information, surprise, or uncertainty inherent in the variable's possible outcomes. While I could easily use entropy as a metaphor for APIs in the physical sense, it is really the appropriation of it for information theory that really brings it home for me. Entropy in Shannon’s time was centered around noise or static in communication, but when you look at how APIs enable communication between systems, and allowing web, mobile, device, and network applications to communicate, this static or noise reveals itself as friction, errors, outages, instability, unreliability, and misaligned business and political priorities. 

 Think about the level of information one encounters when it comes to putting APIs to work these days. Consider the surprise one encounters when seemingly similar API resources speak entirely different dialects or behave inconsistently. Stop to think about the amount of uncertainty that exists between each version of an API, let alone each version of an API across the increasing number of APIs your average organization depends upon today. The velocity at which an organization moves, or should be moving, considered alongside the velocity of each individual API being published or consumed, reveals the reality of API entropy on the ground within your average enterprise organization, as well as the industries in which they operate. When an API and resulting integration or application is brand new API entropy is usually relatively low, but as momentum increases, and the number of consumers increases, entropy will ultimately increase and contribute to the eventual decline of  an API, the applications they power, and even platform that they operate on.

APIs work best where the cognitive load involved with putting them to work is low, where common patterns are employed, and predictability and reliability are high. The reduction of API entropy within API operations and communities can come in many forms. Popular API documentation tooling like Swagger UI, Slate, Postman, and Redoc help reduce API entropy by taming the information surrounding each API. API specifications like OpenAPI, AsyncAPI, and JSON Schema help reduce API entropy by standardizing the surface area of each API and reducing it to a common vocabulary that an increasing number of developers, commercial services, and open source tooling are familiar with. OpenAPI forces API providers to reduce the information a consumer needs to digest when integrating with an API, and has the potential to reduce surprise and uncertainty throughout the life of each API, and the journey of each consumer putting it to work. 

When you also deliver APIs using common standards that are defined using open specifications like OpenAPI, AsyncAPI, and JSON Schema, you further reduce API entropy across operations and within an industry. PSD2 defined using OpenAPI and JSON Schema reduces API entropy for banks, and across the European (and UK) financial sector. The CFPB in the United States considers the adoption of similar rules here in the US will further reduce entropy for banks and the financial sector on this side of the pond, but ultimately globally. FHIR defined using OpenAPI and JSON Schema will reduce API entropy for healthcare providers, and the entire healthcare sector in the United States. Something being driven by agencies like CMS, HHS, and the Department of Veterans Affairs through regulatory guidance and adoption of FHIR, while also actively using OpenAPI as part of their API lifecycle. We are seeing this play out in the travel, transportation and other leading sectors that are looking to reduce the resources it takes to deliver web, mobile, device, and other infrastructure, while also ensuring that enterprise organizations are more agile, nimble, and competitive, and the industries they operate in are more healthy, active, and interoperable. 

API entropy is experienced as friction throughout the API lifecycle. High API entropy within business sectors that power our economy can be seen in the lack of access and interoperability between vendors, institutions, and government agencies. When you are down in the weeds of an organization API entropy just looks like API chaos, and from the position of someone who studies the 250K of how APIs are evolving, you begin to see API entropy as something similar to what is happening to our physical natural environment(s), something that long ago reach unsustainable levels, but is something that can be managed if more of us realize that we are all in this together, and get to work on more specifications, standards, and guidance, while centering our commercial services and open source tooling around these standards. Keeping API entropy low is needed to continue API growth and expansion at the current velocity, and will be something that slows the growth in key industries and large sections of our economy if we don’t reduce the entropic pressure that exists across the API factory floor that first emerged in leading technology companies, but in the last decade has emerged within every mainstream company, organization, institution, and at all levels of government.