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.
Read Complimentary Relevant Research
Top Strategic Predictions for 2019 and Beyond: Practicality Exists Within Instability
Technology-based change is happening continuously, and most organizations struggle to see the change in advance. Continuous change can...
View Relevant Webinars
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.