“Breaking Bad” on APIs – Lessons Learned – Part 2


If you haven’t read Part 1 of this series, click here.


Organizations often decide to build an API without fully considering key success factors or without first engaging their stakeholders. I saw this first hand at a previous employer and it is very painful, not just for the company, but for the consumers of the API, which can have long-lasting repercussions.

In either case, the risk is that the API does not fit the needs of its API consumers. And APIs that don’t fit the needs of consumers have a high cost: limited adoption by developers and ultimately, a failure to meet business objectives. Once the API is designed and built, undoing these mistakes is difficult and time-consuming.

In most cases, you must start over again, redesigning a new API, implementing it by connecting to backend services, then rolling it out again to the developer community. Worst of all, you will have to transition all existing users to the new API. This will require additional work which they may not have the time or willingness to do. At that point, you’ll be faced with a tough choice – continue to support the original API and its users until they eventual (hopefully) migrate, or shut it off and potentially alienate and lose those users.


Another common pitfall of API programs is allowing the design of your API to be dictated by the constraints of internal systems or processes. This is never a good idea, but is particularly perilous when the backend functionality lives in legacy systems whose data schemas are overly complex or whose business logic has been extended over the years using hard-coded workarounds and convoluted logic. Exposing this kind of dirty laundry to your API consumers is a recipe for failure. APIs modeled after internal systems are difficult to understand and use and developers simply won’t invest the time it takes to become productive with them.

What you need is an API that is simple to understand and easy to use. Developers should be able to assess the functionality of your API and start using it in just a few minutes. The only way to deliver that kind of ease of use is to design for it upfront.

Next up, “Tips to building a successful API”

Until next time, Rob

Not all APIs are Created Equal – Overview – Part 1


To continue on from my last post on API’s and their Business Value I did a few years ago.  I thought I would write an updated post on API’s (Application Programmer Interfaces) do a little deep dive. APIs have had a big impact on my last role and bigger impact on my current role as a PM @ 5nine Software, and thought I would share my knowledge and research so far. APIs are not scary 🙂

APIs are not new. They’ve served as interfaces that enable applications to communicate with each other for decades. But the role of APIs has changed dramatically in the last few years. Innovative companies have discovered that APIs can be used as an interface to the business, allowing them to monetize digital assets, extend their value proposition with partner-delivered capabilities, and connect to customers across channels and devices.

When you create an API, you are allowing others within or outside of your organization to make use of your service or product to create new applications, attract customers, or expand their business. Internal APIs enhance the productivity of development teams by maximizing re-usability and enforcing consistency in new applications. Public APIs can add value to your business by allowing 3rd party developers to enhance your services or bring their customers to you. As developers find new applications for your services and data, a network effect occurs, delivering significant bottom-line business impact.

For example, Expedia opened up their travel booking services to partners through an API to launch the Expedia Affiliate Network, building a revenue stream that now contributes $2B in annual revenue. Salesforce released APIs to enable partners to extend the capabilities of their platform and now generates half of their annual revenue through those APIs.

Next up, “Breaking Bad” on APIs – Lessons Learned”

Until next time, Rob.