The nature of APIs
In a digital economy with open business ecosystems, channel experiences and backend systems evolve at different speeds. Nevertheless, an engaging experience must combine the two. Being able to see health statistics is useful, for example, but being able to do something with those statistics in the context of your personal health is the differentiator. Thus, truly engaging apps must leverage data and functions across backend systems of record as well as smart systems of insight.
The basic mechanism for sharing across team and organizational boundaries is called an API. Modern APIs are flexible ways of projecting capabilities to an audience outside of your own team, in a controlled fashion. When done right, APIs enable enterprises to innovate faster and reach new audiences. Twitter has an API that allows you to tweet using the app of your choice; you don’t have to go to twitter’s web site. Amazon.com has an API that allows a merchant to plug into their retail platform; you don’t need to create your own merchant portal. Your own enterprise probably has an API that allows one of your mobile apps to talk to the backend customer system; the mobile team does not need to understand the intricacies of the way the member system works.
- APIs enable an open ecosystem, creating easy and ubiquitous connections between different source and channel solutions
- APIs control exposure and sharing of data, as the owner of the API you decide who you want to share with and how much
- APIs have built in security and audits, they are much harder to “hack” than general purpose software
- APIs can bundle data from multiple sources, freeing the API consumer from having to understand the underlying system topology
- APIs deliberately disintermediate the channel experience from the backend systems, thus creating a two speed IT environment
APIs are the integration highway of a digital enterprise. This integration highway, which powers an open and differentiating business ecosystem, provides value far beyond that of a simple IT construct.
What makes a good API?
An API is the same as an Application Programming Interface, right? I mean, that is what the acronym API stands for? Not so fast… Things are not always quite what they seem; indeed the IT industry tends to reuse old acronyms in new ways.
Think of an API as a product. You carefully craft it so it’s attractive to the intended API consumer – so that it sells. It neither matters whether that consumer really pays for the API nor if she’s outside your enterprise or part of a different team inside it. You want her to use your API, because she creates value for both of you when she does. An API that is not being used, because it is not attractive to the intended consumer, is not particularly useful.
The product nature of APIs is fundamental to their power. It also makes them very different from old-school application programming interfaces. An old-school application programming interface represents a piece of software that you have built and deployed. A modern API represents a package of capabilities that’s attractive to an audience independent of any specific piece of software running in your back end. So although modern APIs do include a defined programmatic interface, they’re deliberately designed from the perspective of the intended consumer, an abstraction of something specific and useful.
When looking at an API as a product, before you develop one, you should ask yourself these key questions:
- Who are the intended consumers?
- How are you going to reach these consumers?
- Under what terms and conditions can consumers use the API?
All three are important for creating a good API. If you don’t know who the intended consumers are, how do you know what is attractive to them, what they need from you? If you don’t think about how to reach the consumers, how can they ever find your API and use it? If you don’t include terms and conditions, be that on security or traffic volume, how can you maintain operational control and quality?
In the case of your internal APIs, the consumer is always one of your colleagues. Simple, with no need to think further, or is it? Do the teams building mobile apps need the same data and functions as the teams building system to system integrations? Probably not. Do you have an opinion on the level of security required to access member data and the amount of traffic that can be allowed without prohibitive cost or quality of service issues? Probably yes. Even for internal use cases there is significant value in adopting a product centric view on the APIs that we build and share.
