The above has been easy to understand. While I’ve been giving API Economy talks in various local and international events, I have noticed that some of the audience have difficulties to understand the difference between Application (app), API and Integration. How could you understand DX if you don’t understand the basics?
Since APIs have taken a significant role in service development, it’s no surprise that the amount of public APIs has been growing rapidly since 2014. APIs are sometimes seen more as products per se and sold to developers from stores much like average Joe or Jane buys applications from Appstore or Google Play. APIs have become commodities for application developers. This has lead to the birth of API Economy. (Moilanen et al.)
But all APIs are not only sold as procucts as is. Some of the APIs are not sold at all as it was discussed above. APIs are also often additional components of SaaS model services. For example data is not manipulated only with help of graphical user inteface such as browser, but also with APIs. APIs are used often in parallel with GUIs. GUI is for humans and APIs are for machines and applications. APIs are preferred and effective tool in automated data manipulation. Still the question of value API should provide has been untouched. API is the hotspot in the chain as described in the above picture.
API provides access to value proposition
Amancio Bouza has done a significant role in Swisscom as technical lead of the API program and on the job made a discovery, which is also fundamental idea in the book he’s writing about API product management. According to Bouza “Ultimately, the API is only about the interface to the value proposition, not to the application.” API is a vessel to the value proposition.
Bouza emphasizes the value in the concept. API as technical interface is not worth a penny if id does not have any value for the customer. “Your primary goal is to provide value to the API consumer, help the customer to get his job done!“. This is also fundamental element of developer-centric approach introduced in this 100 Days Dx series.
According to Bouza API development can be divided to application-driven API and customer-centric VPI approaches. The first one is a trap in which most companies fall. They focus on generally exposing APIs and focusing on their internal applications. API is merely an interface to an application. In the latter focus is on the customer and their pains, gains and needs. In other words API is now interface to a value proposition - it solves the problem.
An example would be customer data and how you could build API services on top of it. You might take the application-driven approach and offer customer data to partners. Or you could select customer-centric approach and build identity confirmation service on top of the data.
For Bouza value proposition is non-negotiable and must have element of any value proposition interface. But value proposition alone is just an idea and thus is not valuable to the customer (developer consuming the API). You should go to some startup pitching event and you’ll see a lot of value propositions. The package still needs the technical interface which must have great developer experience (Bouza uses the term user experience).
Developers select the tools
From my experience application developers are given more freedoms nowadays to solve the problem with what ever means they see necessary. Of course they are given some boundaries, but they are becoming more and more the decision makers when it comes to APIs. Some claim that this is bullshit. They say that business people make the decisions.
That is not the case but more and more developers are becoming technology decision makers for a few reasons. Firstly, managers near the developers are often long term developers too and thus value easy to use tools and understand the value of developer friendliness. Secondly, the business people have no idea if a service can be integrated or used in solving the problem or not. They might claim to know, but their knowledge is based on marketing jargon and promises given by the vendor (expecting to make sales). There are cases when there’s just one API and the choice to make is 1) use the given API (if it makes sense) or 2) build a workaround (scraping or other).
Companies develop API products for the developers
You might be wondering how the developer focus is visible in real life. One of the developer friendly companies is Pusher. Their website indicates that they see the developers as primary customers: “Developer experience is at the forefront of everything we do”. In fact, if you go to Pusher website, you’ll notice that it is directed at developers. Menu has “Developers” item and right after the call for action “Get free account” you’ll see code!
Some more to read from 100 Days DX
- #85 - Great Developer eXperience requires fluent internal workflow
- #84 - Theory of Economics of Developer eXperience
- #83 - The Space of API Design Decisions is missing
- #82 - Purpose of API Evaluation Framework
- #81 - Should We Move to Stack Overflow?
- #80 - Four data driven ideas for improving API documentation
While you are here...
Check out Platform of Trust in which I've worked to enable best possible developer experience!