Why APIs? Anatomy of an Internal API Initiative
In a recent post, I made the argument that the key to bridging the gulf between IT requirements and those of the new app economy is an API.
We categorize the API initiatives that support the app economy in four flavors - Internal, Partner, Customer, or Open - according to the different roles that app developers can play.
So what does each of these API initiatives look like? What are common scenarios in which you see them employed and how do you align your business goals with a particular strategy? Let’s start from inside a business with an Internal initiative and work outwards to the Open initiative.
We've observed that many successful API initiatives are done in stages. With each stage, businesses can build on previous projects, and assume more risk and larger investment more easily.
Anatomy of an Internal API Initiative
Loners: One of my favorite use cases for the internal scenario is what I call “Loners”. There are many organizations within a company in which there are no developers – that is, no technology people to make an app. But these organizations often have budget to hire developers to build apps. For example, a marketing department can often take the budget they may have applied to creating Web pages in the past and redirect it to building apps based on APIs. This can give quick wins, but can also leverage the marketing expertise to help gain acceptance for a new strategy and your API initiative.
Cross Departments: APIs solve the problems of keeping things secure and providing easy access. These are common concerns even internally - when departments are trying to work together to create new value for an organization. Today, cross-departmental initiatives often involve big program management apparatus and onerous processes.
If businesses followed the archetypes of open APIs within departments, they could do a lot less planning, a lot more doing. (We’ll look at the Open initiative in detail later, but for now think Twitter, Foursquare, or Facebook at the archetype.) It would be as if businesses thought of the Twitter ecosystem as one company with developers building Twitter apps in different departments. What level of reuse or value could developers take from existing internal systems to their new initiatives? The answer is 100%.
Making IT more productive
Systems of record have both vices and virtues. The most important virtue is that they make money. If you’re in the hotel business, it’s your reservation system; if in finance, it’s your stock trading system; in the automobile business, it’s your system to sell vehicles and predict economic cycles.
Systems of record are also stable. Because they’re stable, they are also often slow moving and don’t allow for core systems to keep up with market evolution. By thinking as a platform – by putting APIs between the systems of record and the apps – you can achieve agility and flexibility and take advantage of the stability of those systems.
IT has tried to do this several times through history - most recently with Service Oriented Architecture (SOA) and with mixed success. With APIs we have strong archetypes and businesses are proving success with API-based platforms.
Next time, we’ll look at the anatomy of a partner API initiative.