Blog post

Don’t Let API Management Wag the Dog

By Eric Knipp | August 02, 2013 | 2 Comments

I had a great week at Gartner Catalyst where I spent time with many clients and got to catch up with friends old and new. Gartner analysts speaking at our conferences not only present on-stage, we spend a large amount of our time in one-on-one sessions with attendees. During these one-on-ones, we try to help our clients answer their most important questions and solve their most challenging problems. As you can imagine, at a conference with 1500+ attendees, there are a lot of different questions to go around. My most popular client question came down to, “How do we select and implement API management capabilities?”

While working with attendees to answer this question, I noticed a concerning trend. Attendees interested in talking to me about criteria to use in selecting an API management product often could not articulate an API strategy; even worse, few had spent much time considering the importance of API design. I definitely felt the focus was more on buying a solution, rather than understanding the fundamentals of API strategy, design, delivery, and management.

Rolling Without a Strategy Will Cost You Money

Why are you building your API? A lot of people tell me they need the API because of a particular mobile project (or at least, that’s how they’re funding the development of the API). When I ask about the long-term plans for the API, I get a lot of blank stares. That’s a problem.

Your API might really just be for that one mobile app. But I doubt it. The real value of an API lies in its ability to provide access to many new channels that were previously very difficult to reach – mobile, social, third-party developers creating new apps, and so on. On top of that, your API might be relevant in a partner integration scenario, or even for running your own non-mobile Web applications. If you make design decisions in a vacuum – based on the presumption that the API is just for the mobile app you’re currently working on – you will paint yourself into a corner.

Maybe it is worth being painted into that corner because of the learning you’ll get by executing quickly. That’s a position I can understand and respect. But it isn’t one that I endorse taking by accident; it will cost you money down the road. So, start by having an API strategy that takes explicit positions on what the API is and is not intended to do and how the API strategy aligns with your business strategy. My colleague Gordon Van Huizen has written a great document on the topic.

API Design is Important

I’ve written about it extensively, but just to make it clear, one more time: API design doesn’t require you buy any new technology. You should begin your API design before, or at worst, in parallel with your exploration and purchase of an API management solution.

Without an explicit process for API design, the temptation to turn it into a supply-side exercise is great. The odds of building the wrong thing become much higher. Without an understanding of what a good API looks like for your audience(s), you’ll also have a harder time prioritizing capabilities available in the API management product space. Loosely translated, this means that in the absence of understanding, you’ll substitute money and pay for a bigger, heavier, and more expensive API management platform than you really need. Skipping API design is bad on a lot of fronts.

The first step in doing an API well is to create a well thought-out strategy. The second step is to do a great job with design. Please don’t skip these steps.

Comments are closed


  • The responsibility of providing high quality materials and parts have grown mainly because of the competition in the market and therefore manufacturers want to make sure that they have tools that can allow them to come up with zero error parts that can make their work easy.

  • Ivan says:

    Could not agree more. API and infrastructure or enabler, not as business strategy. Yes organizations need an architecture to support them, but API are not an end to themselves. Too many organizations are trying to find business models for their API strategy and not an API strategy for their business model.