What it Means for an Organization to Have an API Mindset

This article was prepared by a guest contributor to ProgrammableWeb. The opinions expressed in this article are the author's own and do not necessarily reflect the view of ProgrammableWeb or its editorial staff.

How do you arrive at an API centric enterprise? You get there with an API culture. Then, how do you cultivate an API culture? You have a team with an API mindset. Then, how do you develop an API mindset? Like good API design, it's simpler than you may expect. Just asking the right questions can create an API mindset.

APIs enable us to break monolithic programs into smaller pieces and still render the same function or service. When all the individual pieces interoperate through APIs, they can replicate what the singular large program use to do.

APIs enable access to data and services we need. Putting more responsibility on the other side of an API lets an application, especially Web or mobile applications, have a consistent channel they can depend on for data and services, no matter the platform of the client. This is especially critical for mobile applications which have a strongly delineated client-server model.

APIs enable us to extend our business value. By making data and services more readily available, new opportunities are created as partners innovate with our APIs, mash-up our APIs with others, and find ways to leverage the assets we offer.

But how do APIs come to be? Some will be instantiated through business demand, as the deliverables of projects driven by business objectives. Some will be delivered as necessary interfaces to enable system and application integrations. But some can come about through inspiration of engineers with API mindsets.

An engineer can use the following exercise to increase their API mindset. Lets define “domain” as the space you work in, or are an expert in. Following this short acronym of suggested thoughts, APIs could emerge that were not previously obvious. Some of which, may prove to be impactful to enterprise efficiency and/or business revenue.

A - Assets. In your domain, what can be made accessible that is of value? For example, can you provide access to data that tells a client “What is the average time between users landing on our site to submitting an order?”, or “What percentage of our items are damaged in transit from the warehouse to the retail outlet?”, or “Where is this specific term referenced in all our digital content?”, or “Based on current buying velocity of a specific product, when will that product be out-of-stock?”. Most engineers may be surprised at how much value they can make accessible to clients with just a query or some simple calculations. Imagine the value to your internal and external clients if all, or at least the most critical, of those answers were accessible via APIs.

P - Pass It On. In your domain, what could you delegate to an API service? For example, if it takes several steps to collect the information you need about products, should you relinquish that function to an API service for all your programs to use? Can you delegate part of “code review” to an API that can interrogate a source file for expected standards and structures in the code?

I - Intuitive. In your domain, when you think about the APIs you can offer or would like to consume, think about how to make them intuitive from your client's or provider's perspective. Think about the language and terms used, the schema of the data, and so forth. When a developer decides to use an API, the more intuitive the API is, the easier, faster, and more successful its implementation will be.

Asking these questions also creates a mindset of “Business Intelligence”, and can inspire engineers to find ways to derive value from their domain. If APIs enable us to interface and share assets, then creating new assets and insights to channel through APIs is a critical part of the API mindset.

Exercising these questions (Assets/Pass It On/Intuitive) will both create a tendency to architect with APIs in mind when working on new development, and will spawn ideas for valuable APIs against current systems. Of course, you have to be careful of the other extreme where “everything becomes an API”. A report still has its place, and should not be obviated by calling an API to get each line item. This is where you benefit from a board, such as an “Architecture Review Board” and a Rock Star API product manager that will govern direction of your API product.

So, if you want an API centric enterprise, you need an API culture, which requires engineers with an API mindset, and the Assets/Pass It On/Intuitive thought exercise can help you achieve that.