Everything as an API
The future of service model design and creation in business
Application Programming Interface (API)
In software engineering, APIs are abstractions of modules which contain their operations, inputs and outputs, and define functionalities that are independent of their actual implementation. This allows the underlying implementation to vary and change, without compromising the interface.
Abstracting this definition from computer programming, an API is the interface of a system towards other systems which defines the operations it can perform, the expected input and the resulting output.
Every aspect, or certain aspects, of a system can be exposed that way to allow linking it with other systems for a larger purpose. Whatever happens inside of the system after taking the input and before returning the output, is irrelevant for the use of the API.
Our Embedded APIs
The principle of an API is not at all exclusive to computer programming. Many daily human interactions can be described and thought of in an API-like structure.
For example:
Upon entering a restaurant, the waiter provides the menu, which is akin to an API description defining all possible inputs (the order), the output to be expected (description or picture of the food), as well as the transaction cost. Per this API definition, the “order” function can then be used with a subset of all possible inputs. After providing the verbal input for the order (with the implication of the monetary input to follow later) the output is then expected, without a second thought of how it is produced. The waiter, as the interface to the restaurant, hides all internal complexity.
The main difference to the world of computer programming is that these APIs are not well-structured, not clearly defined, and not easily explorable. Everything about them is implied in the context of human interaction and behavior, learned through experience and potentially mis-learned as well. This, in the eyes of a systems engineer, would be a weakness. The system is not precise and hence errors can occur randomly — the system is not deterministic.
APIs Drastically Increase Efficiency
The greatest feature of a good API is reliability. As long as it is clearly defined and performs to expectation, it allows System A to pass work to System B with perfect predictability. This enables System A to focus on its core value and rely on the performance of System B as per the implied contract.
In computer programming, this enables software developers to make use of systems other people built for certain functionality, and to only focus on what they really need to develop themselves. That is a huge time saver and allows every actor to completely focus on their core value add, which further improves the overall utility of the system. If everyone had to re-implement all functionality all the time, there would be hugely different quality grades. If every actor can focus on what they are good at, this provides higher-quality components for the whole system to use.
Same can be applied to human interaction. The fact that there exists the concept of a “restaurant” — which is a human-defined concept that comes with a lot of expectations — improves the whole process of keeping oneself fed. There are locations with people who specialize in preparing food and come with standard procedures of interaction. This saves time and ensures a certain level of quality. A meal could be self-prepared, with uncertain outcomes, or one could try to query other people to prepare meals (e.g., neighbors), with lengthy discussions about why and how. Restaurants are standardized in output and transactional procedure, which makes them very efficient.
Especially in a world of high specialization this works perfectly. There could be an API per system, or even an API for a metasystem (i.e., what Delivery Hero is for restaurants) to completely rely on. The only weakness is the still lacking documentation and structure, as well as a continuous (but decreasing) lack of automation at the API interface.
The Power of the Value Chain
Systems are very rarely a singular unit of performance for a service, without any interdependencies. When the “order” function is used on the waiter with the correct input, he does not actually prepare the food and deliver the output. Behind the scenes, he queries another API — which is the kitchen — to which he provides the order as the input and then expects the food as the output in order to be able to serve it. At the same time, the kitchen staff, after receiving the order, is relying on resources to be available, such as raw ingredients and tools. Having these restocked is another process/API, which involves a purchaser and a wholesaler. The wholesaler has a relationship with the farmers who provide the raw materials.
Value chains are a creation. People connect systems in certain ways to be able to create an output that satisfies a need for the purpose of making a profit with that. Restaurants could not exist if consumers were unwilling to pay a steep premium on the price of raw materials in order to be served a complete meal in a restaurant environment.
While many of the existing value chains in the physical world take a long time to evolve, they are literally plug-and-play in the digital world. Creating services based on a chain of APIs is a matter of hours in computer programming. Yet in the physical world, the APIs are not well-defined, but vague, non-trivial to discover, and changing over time. Negotiations happen between humans and take a long time. Every additional party that is needed to create a value chain increases the time to create it exponentially.
What if the physical world had deterministic APIs? What if we could plug-and-play existing physical services together in a matter of hours to create new value? What if negotiations could be automated through target settings from all involved parties, with artificial intelligences negotiating the best interaction on their behalf in a matter of microseconds?
Potentially, it would put anyone into the position of being able to create a highly complex value chain within short timeframes, and cash in on them if they fulfill a market need that was previously unmet. Perhaps the solution could even be rooted in a blockchain that utilizes smart contract language.
See a need for baby food from Germany in China? Drag-and-drop together selected German brands, some quality logistics, and a payment provider; brand the whole thing and make an enjoyable margin for being a portal without any inventory or fixed cost.
This Is Already Happening
There are a whole bunch of start-ups that are already turning traditionally human-based interactions into APIs. Think about Uber — they are API-ifying drivers through an application. At the push of a button, you receive a standardized service at a standardized rate with a standardized level of quality. Taxi drivers have transformed from being a not well-defined human API to being a very well-defined digital API.
The same is happening for many other industries, such as massage therapists, hair dressers, personal trainers, handymen, etc. Whole industries are being turned into APIs for others to use. And that not only through the interface of the company who does it. Uber, in turn, also provides an API for anyone to utilize their service in their own value chain. Calling Ubers from Google Maps, using Ubers for delivery services, having Uber pick up your Tinder date,… all possible through their API.
Necessary Considerations
When working in such an abstracted value chain, topics that are clearly defined today will need to be re-evaluated.
Who owns the consumer and transactional data? Businesses today are highly concerned about knowing their customers, being able to understand them, and communicate with them. Can the end customer still be an effective consideration of your service, or are your API users your new customers to know?
How can a consistent user experience be ensured? If the implementation of the service abstracts multiple services and hence has multiple businesses interface with the customer at different points in time, can the user experience still be consistent? How can standards be enforced?
Moving Forward
We will see more and more businesses embrace APIs as they become a source for new business. Those early to experiment with the possibilities will be able to reap the most benefits, since a discovery crunch sets in when too many competitors participate (as it was with having a website, having an app, etc.). At the same time, it will become one of the main sources for business for many industries and, thus, indispensable for long-term survival.
In order to take advantage of this emerging opportunity, start thinking about the implied contracts in your business. What is the input/output, who is the user of the service, and how could this be phrased in a standardized way? Do your customers already have, or use, systems that could utilize an API you could provide? Thinking through the fundamentals from this perspective can open your mind for the potential that APIs can unlock.
Special thanks to Steve Ehrlich for input and edits.
MING Labs helps its clients create and implement digital solutions for their business needs. We are entrepreneurs with design and technology in our DNA. Today we call Berlin, Munich, Shanghai, and Singapore our home, with a strong team of 60+ digital experts hailing from more than 17 countries and different disciplines. Our proven user-centric process ranges from strategy to concept creation and ultimately execution of digital products.
Spitzberg Partners is a corporate advisory and investment firm headquartered in New York that provides strategic counsel and investment insights on international political, economic, technology, and security matters. Spitzberg Partners assists innovative companies from a diverse range of industries in navigating today’s increasingly complex political, business, and regulatory environments around the world. Selectively, Spitzberg Partners provides seed funding for highly disruptive start-up companies in the technology sector.
