Usability of APIs – Developer experience (DX) and Developer Journey

Developer Journey

I have not found a lot of references or a formal definition for Developer Journey on the web. So here is my personal take on it.

To define the term in perspective to writing an application around a concrete API that the developer has in the beginning no previous knowledge let’s look at what the words means by themselves:

The developer in this case is a self-motivated, often external software development professional and/or aficionado.

The journey is the inauguration to the specific software ecosystem that exists around a specific API or platform. More literal, it is the trip someone has to take from becoming aware of a specific API, or a category of APIs including selection of a specific API from a set of competitors, finding out how to implement a certain idea, signing up for API access, implement (hack) the first simple use case around the API, make it to a fully-fledged app(lication), publish it, and eventually monetize it.

Overall it is about how developers experience their first and repeated encounters with an API and how they and their perceptions of the API change along the way. The journey starts with a first encounter or before with just hearing or reading about it, goes on through onboarding to releasing an application using the API in question.

Some factors that are influential are API Discovery (How do potential developers find out the API exists at all?), Developer Evangelism (How do they find out if they want to use it?), API Onboarding (How do they sign up? How easy is it to implement the first “Hello World”? Do they get an SDK is case the API is very complex?), Developer Relationship Management (If they stick with the API how do they receives update about changes and enhancements? Is the price right, are terms and conditions in a way that they want to stay with it? Do they get any help to publish and advertise their applications?)

Developer Experience (DX)

The way I would see it, it is the part in a Developer Journey that is most closely related  to the concrete hands-on experience of an API integration developer (be it a mobile app development hipster or a traditional SOA-type integration developer) and the daily ups and downs of developing an app(lication) around a certain API and platform.

It is influenced by key elements as the technical design of the API (how RESTful is it, how adequate for a purpose, certain protocols and common practices respected) and documentation (is it concise, well-structured, interactive, …).

Purely technical / API centric DX discussions derive from UX, and interaction design. In this case the user is the developer and the interface being used is an API. In this context there is currently a lot of discussion proper ReST style of APIs, “hackability” of URLs, etc. When you extend the term to SDKs or libraries that wrap an existing, the discussion is not so much about the URLs, RES and HTTP, but on the interface this piece of software provides to the potential user.

DX - Additional reading

For DX there is some published material available. Some additional can be found in the attached article (PDF) which takes it very scientific and was presented an IEEE conference (http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6225984). If you want it somewhat lighter look at the Pam Fox presentation in SlideShare (http://de.slideshare.net/wuzziwug/developer-experience), or the UX Mag article (http://uxmag.com/articles/effective-developer-experience).

Retrospective 2013 - The API Management Industry

I have been making APIs for a decent time now. Although always at the same company, and as early starters in the API game never using any 3rd party API Management Software. At some point an entire industry of vendors of API Management Software caught my attention. But as fast some of these vendors appeared as fast is the change in this young market. The year 2013 has seen some companies disappear again or finding cozy and warm homes with larger software corporates. Here is my "The year 2013 in API Management" retrospective.

One of the big players is APIGee, which was formed out of a company making hardware accelerators for XML transformation they found their destination in API management nowadays. They managed to raise $35m in venture capital in 2013, so they are likely to stay independent and afloat for some time.

Positioning itself as serving rather mid-sized companies and API demands, 3Scale has also received fresh funding ($4.2 million) in 2013, making it one the better bets for sticking around and staying independent, for some time.

Also, MuleSoft has entered the API management. They have a special focus on API discovery, underlined by the acquisition of ProgrammableWeb and boosting APIHub. All activities and acquisition boosted by raising $37 million in early 2013. They have a running software business for Enterprise Service Bus and Enterprise Integration, so likely a candidate to stay around for a while.

From the a more sturdy and traditional SOA and Enterprise Integration background SOA Software also offers API management these days, but with a twist into the corporate taste, addressing and offering to mitigate compliance risks as well in addition to the typical API gateway and analytics offering, and is considering themselves as a leader in Application Services Governance. Their last venture round seems to have been in 2006 and they have been announcing good YoY growth figures for the last couple years. 

Another of those I'd call the big players is Mashery. They were acquired by Intel in 2013. An interesting point is that Intel is obviously really willing to buy into the API industry, proof being the acquisition of hackathon platform Hacker League in late 2013
Next there is Layer7 which comes a tad more of an old-school SOA touch in the product portfolio. Also Layer7 has been acquired by CA in 2013.

A full consolidation was what happened to Apiphany, which was acquired by Microsoft and incorporated into Azure cloud platform, disappearing as an independent brand and operation.
And there are players coming from rather traditional EDI background as Axway that are trying to get a foothold and the API Management Business as well.

To me rather interesting newer player is Apirary. They don't offer the full range of API management tools as most of the other but have developed a very cool and new set of design and prototyping tools for API engineering. They also secured $1.6 million in a funding round in 2013.  

The WebServius offering falls into the group of data centric API enablers. The two things that seemed notable to me are that they work very clearly on the notion of “data monetization” and there a  proxy-less API management solution for use cases where latency is a concern.

If you have additions to this or, comments you need to make, or feel your company or employer has been misrepresented let me know.