When Good API Design is a Waste of Time

The idea that good design is essential to building great products and services has become a truism in our industry.  Most of us intuitively understand the idea that expending effort on the design of our code, system architecture and APIs will payoff after implementation.  I'm certainly a big believer in the power of good design for the API space, but I wanted to explore a situation where a design focus might not be necessary.

Consider the case of a small business offering a cloud-based service product for a niche market.  If this business chose to invest in a well-designed, developer-centric API, at a minimum they could expect:

  • A reduced learning curve for developers consuming the interface
  • A reduction in troubleshooting time
  • Increased interest from their developer community

For most audiences, these are goals worth achieving.  Indeed, this is why we emphasize good design for APIs in the first place - the benefits fit remarkably well with the main reasons for embarking on an API strategy: reduced cost and increased adoption.

But, in my conversations with connectivity professionals from larger organizations, it is apparent that not all service vendors see the value in investing in this type of design effort.  Developers and architects are bursting with  tales of forced integration with service providers who have simply thrown an ugly or barely functioning interface on top of  core component.  It is in these scenarios that we hear about laughable attempts at implement whichever API styles and features are in fashion.  'REST' and 'security' become sales-worthy buzzwords that don't live up to their promise when developers get their hands on the actual interface when real project work commences.

In the majority of these cases, technical teams have very little say during the procurement process of outsourced and cloud-based services.  In effect, these API providers don't need to design for their developer audience because they aren't critical to succeeding.  For many years a sound strategy for selling cloud-based products has been to sidestep technical teams and engage directly with the business.  It's frustrating that technology teams are often still left with the responsibility for reducing integration costs regardless of the lack of sophistication in the APIs that they are tasked with connecting to.

Thankfully, the wealth of knowledge and connectivity products in the enterprise space allows these teams to reduce the impact of bad design on the overall project and organization.  Components such as API proxies can be used not only to build a facade for APIs that are being exposed, but also to provide abstraction for services that are being consumed.  In essence, the design burden can shift from the service provider, to the enterprise developer who wraps a poorly designed interface in a more consumable, developer-friendly API for the rest of the organization to use.

As a whole, the scenario makes sense.  Well designed products are based in part a designer's empathy for their users.  Good design involves perceiving a product from a user's view point along with an understanding of the impact that design decisions will have on the user base.  However, an organization that builds an API as an afterthought for developers, who are only viewed as a means to an end, will likely produce a poor API.

Ultimately, building a technology business based on developer apathy is a bad idea.  The industry shift towards API product based integration is empowering technology teams at all levels and services that continue to ignore the needs of their developers will eventually be ousted from the market.  In short, good design is only a waste of time when you don't care about your users.  If  in fact you do care about the developers who will be using your API product, then you need to invest in designing your API with their point of view in mind.

The Author

Ronnie Mitra

Lead Designer

Ronnie Mitra is an expert in enterprise development and integration who leads the CA Technologies API Architecture and Design Practice across Europe. In this role, Ronnie helps companies leverage their burgeoning API potential. Before joining CA, he worked at IBM where he held the worldwide leadership role for WebSphere connectivity products.

Related Articles

Microservices

Applying and Extending DHARMA

This post gives some practical examples of the DHARMA method for API Security in a Microservice Architecture, and also shares some opportunities for extending the model.

Matt McLarty on Jul 9, 2018

Microservices and APIs
API Strategy

Microservices, APIs and Innovation: The Power of APIs

Explore the role APIs play in empowering teams and enabling organizations to innovate.

Mike Amundsen on May 24, 2018

How API Languages Evolve
API Design

How API Languages Evolve

As API systems mature, knowing the history and evolution of various API languages will help organizations create robust and successful landscapes.

Erik Wilde on Oct 17, 2017

Join the Conversation