Note by Al Shalloway: I’ve known Israel Gat for a few years. Besides just liking to be around him (if you’ve met him, you’ll know what I mean) he always has the effect of taking things I’ve known, but not used, and put them in an easy way to understand that provides great insights and actionable decision making. That’s the sign of true genius. Read on, Israel is going to do it again.
Fellow and Director, Cutter Agile Product & Project Management Practice
The grand successes of Facebook and Instagram demonstrated the new economics of the web. The money these days is in breakout hits powered by network effects. Such breakouts are primarily enabled by thoughtfully exposing API’s. Hence, we are witnessing a dramatic increase in the number of web API’s that get publicly exposed (as distinct from internal API’s). We have, by now, reached the level of 8,000 such API’s. Extrapolating the pattern indicated in Figure 1, we could easily expect some 20,000 exposed API’s at one point in time or another during 2013. For most practical purposes, a “web beyond the browser” is getting formed in front of our eyes.
This new “web beyond the browser” has profound implications not “only” on the way we do software, but on the way value is generated and delivered. Essentially, the nature of assets changes in a profound manner. Your company’s assets might be physical, but they have corresponding information representations in your company’s pipes and vaults that are potentially valuable to a broad spectrum of applications. For example, various users are already spawning off bazaars on top of the Instagram photo sharing service (click here and here for recent articles on the subject). Imagine the limitless possibilities that could open if/when an advertising API is exposed by Instagram.. Needless to say, other kinds of API’s that might potentially be exposed by Instagram could be most intriguing…
From a software process perspective, the effects of the “web beyond the browser” manifest themselves in quite a few ways. Here are six of the more noteworthy ones:
- The changing nature of the business you are in: More often than not, value for the end user is not generated by your own programming team, but through an eco system of developers that build their apps on top of your company’s exposed API’s. Schlumberger’s Ocean app store – screen scraped as Figure 2 below – is a good example. Schlumberger, who actually defines itself as an “oilfield service provider,” is (de facto) in the business of software these days. Similar metamorphoses are taking place all over.
- Business design: The way an API is exposed determines the nature of the business the company is pursuing. Figure 3 illustrates about twenty kinds of business designs that are driven through the different ways in which an API is exposed. Hence, exposing an API becomes as important a decision as any traditional business design decision such as how a company discovers and develops its customers, differentiates its services or goes to market.
- The systemic uncertainty of value generation: Traditionally, a product team developed a whole application as the primary vehicle to generate (and thence recapture) value. Nowadays, value is more and more generated through applications that other folks, possibly in a developer community, develop on top of the API’s the company’s product team implemented (and exposed). Quite often, such apps create value in novel ways that had not been foreseen nor foretold at the time the API was exposed.
- Your customers are your developers: Developers might or might not pay you directly (see Figure 3 above), but for most intents and purposes the folks who develop the applications on top of your API’s are the primary target clientele the product team needs to cater to. The success, or failure, of your exposed API’s is only as good as the quality of the applications produced and delivered on top of them.
- Open Source style of governance: You can incentivize the developer community to code to your API’s in various ways, but you can’t manage them in a traditional fashion. As a matter of fact, an Open Source style of governance is usually the most effective way to manage an expanded software process that incorporates the developer community as a pivotal organizational construct.
- The changing role and skills of the product manager/owner: Historically, decisions about API’s and their design were largely the realm of architects and programmers. In view of the business design implications, these decisions are now becoming more and more the domain of product managers/owners. To succeed in defining both the API and the corresponding business model, the product manager/owner needs to excel in architecture, business design and developer relations.
Examining these six changes, it becomes obvious that the connection between the macro – the market – and the micro – the process a firm uses to shape the market – is much tighter nowadays than it used to be. In this new reality, a metamorphosis of the software process is taking place: customers become developers; self-organizing teams becomes developer communities; and, the product manager/owner’s job becomes the definition and monetization of API’s.
In the aggregate, the six changes listed above force companies to shift their focus to full life cycle optimization. Such optimization can’t be attained without major expansion in the scope within which Agile/Lean/Kanban/devops techniques will be applied. My hunch is that we will soon witness the application of such techniques to new and exciting areas. I will elaborate in a follow-on blog post on the areas/industries I expect to be most promising for so doing.
We live in interesting times….