AT&T’s Grade against the 5 Rules of API Management
TechCrunch is one of my favorite sites and they recently posted an article on the 5 rules of API Management. APIs are now a major focus of our program, so I thought it would be useful to look at these five rules and judge how I think we are doing against them. Please feel free to make comments below if you disagree or have suggestions on what we could be doing better. The five rules are design, documentation, analytics, universal access, and uptime.
- API Design: It can be difficult designing a good, RESTful API and this has been a learning process for us (if you are interested in this subject, a good book is “APIs, A Strategy Guide” from O’Reilly). If you look at some of the first APIs we created, like payment and messaging, clearly we could have done better. We have been improving (if you look at our more recent APIs like speech) and we now have good process where we are testing these APIs with developers in our Foundry before beginning development. If any developers are interested in getting involved with our Alpha API program and providing feedback on APIs, please respond below.
- Documentation: We currently have a lot of documentation and sample code to support many environments. We have it on our developer site, within the Apigee devconnect environment, and also some information at Github. The challenge we face is discoverability and usability. We have been focused on the user experience and hopefully developers have found it quicker and easier to find the right contact. Like everything else with our program, we would really like to hear any feedback to make future improvements.
- Analytics: One challenge around analytics is to provide the right amount of data in a form that is easy for developers to use. We have dozens of possible reports covering a variety of areas. I think the difficulty for developers comes as they get APIs from a few different sources. In particular, if they are also getting revenues from a few sources and need to figure out how to manage the various data streams and make the right decisions about their business. It is not enough for developers to just know programming (and at times some marketing), but increasing a knowledge of BI is needed.
- Universal Access: One of the biggest evolutions through my last eight years with the developer program has been around providing better access to our APIs. Going back to the origins of SMS—where we exposed our SMSC either through aggregators or via a difficult onboarding process, it was not that easy to use APIs (and certainly not fast). If you look at what we have now, it is remarkably quick and easy. In particular, the new Playground functionality we just launched makes it super fast and easy for developers to test out and use our APis.
- Uptime: Since we are a carrier, our uptime has always been good.
Considering we just launched the platform in January and have been improving through the year, I am going to grade us a “B-.“ I will say though, when you see the improvements we will be launching in Q1 next year and the future APIs we now have working through the pipeline, I think we can get to an “A” next year.
If developers are interested in our APIs, I strongly suggest you attend our developer summit. Once again, it will be the day before CES at the Palms in Las Vegas. In addition to a day full of solid technical content, this is a chance to talk to our AT&T subject matter experts (and those of other platforms).