{{ searchResult.published_at | date:'d MMMM yyyy' }}

Loading ...
Loading ...

Enter a search term such as “mobile analytics” or browse our content using the filters above.

No_results

That’s not only a poor Scrabble score but we also couldn’t find any results matching “”.
Check your spelling or try broadening your search.

Logo_distressed

Sorry about this, there is a problem with our search at the moment.
Please try again later.

Unless you’re Google, Netflix, or Twitter, you may have found it difficult to build or articulate compelling business cases for your API projects.

While conversations around this subject have long been dominated by how the big public APIs have forged new business models by opening up products and services to the world at large, the harsh reality for most companies is that copying this strategy is not necessarily the right thing to do.

Understanding the real value of APIs

In my previous post on becoming a disruptive digital seller, I mentioned that having the right kind of commerce API is one of the keys to thriving in the new subscription economy. Given the hype around public or open APIs such as those created by Amazon or Facebook, it’s a common mistake to assume that this is what all API strategies need to look like.

But the truth for most businesses, as Brian Walker of Forrester Research points out, is that the internal benefit of owning and operating a commerce API usually far exceeds the value of trying to monetize some sort of public API. He goes on to define this value on three dimensions:

  • Fostering and propelling internal innovation. Right now, the most compelling reason to have a commerce API is to unlock the potential of developers working for your business, by allowing them to easily embed transactional functionality into every customer touchpoint, from mobile apps to social networks and digital marketing campaigns.
  • Enabling new and innovative business relationships. Partnerships, business development, agency relationships, and other mashups take on a whole new dimension when your company’s products and services are easily, consistently, and securely available to trusted partners.
  • Activating commerce opportunities across the long tail. Of course, having a great commerce API is a must for businesses where the rewards of opening up their functionality to third-party developers outweigh the risks.

These are simple enough value propositions – but there is a catch. In order for these things to happen, the API must be easier to use, scale, and manage than traditional methods of integrating directly with back-end systems. Unfortunately, when it comes to commerce and other transactional APIs, this is often far from the truth.

The problem with conventional commerce APIs

To oversimplify a bit, commerce APIs are supposed to be the magic bullets that enable your business processes to easily be embedded into other digital products and services, without having to mess around in any way with your enterprise software.

They’re meant to empower developers who are not necessarily familiar with all the gory details of your systems and processes. Imagine this:

Your social media agency wants to add one-click purchasing functionality to the refresh of your Facebook page? No problem! The Sydney office wants to make a quick iPhone app with localized functionality for their tiny market, next month, on a skunkworks budget? Here’s a URL and key for our API – go wild!

So why haven’t we seen this level of agility, even in organizations that have already deployed APIs?

The dirty little secret that plagues most conventional, first-generation enterprise APIs is that they aren’t much cheaper or faster than the old-fashioned methods of low-level integration or hacking away at the platform code.

Although they technically fulfill their mandate by providing a path for client developers to “get at” functionality, these APIs merely expose underlying services, which means that you’re still working indirectly with the nuts and bolts of the enterprise software.

The most obvious symptoms of this problem? API integration guides that run into the hundreds or thousands of pages, and projects that last months instead of days or weeks.

Those manuals and timelines are needed because developers still need to understand and manipulate the stuff beneath the API.

In many cases, they string together service calls with complex business logic of their own in order to make the desired customer experience happen.

The resulting implementations are often complex, fragile, and costly to maintain, which makes it tough to justify a strategy that relies on these APIs to be catalysts for innovation and agility.

Next-generation commerce APIs

Schooled by these failures, the most innovative companies are just starting to develop a new breed of smart and agile API, in an effort to maximize the all-important internal benefits.

More robust and easier for developers to work with than the first- or second-generation SOAP and REST programming interfaces that came before, they closely resemble intelligent middleware layers that make it simple for internal teams, digital marketing agencies, contractors, or anyone else to “plug in” and embed core commerce functionality into anything and everything.

Without getting too technical, these next-generation commerce APIs take this simplification seriously, to the point where outside developers (say, Bob, the IT intern at your ad agency) can plug bits and pieces of your online store into a campaign without ever understanding a thing about your ecommerce platform.

Everything he needs to know and do is contained within the API itself. For the more technically inclined, this corresponds to Level 3 REST in the Richardson Maturity Model, which is sort of like reaching the holy grail of API programming.

Noted API Evangelist Kin Lane puts it succinctly for the rest of us:

“The latest trend of web APIs is allowing the enterprise to individually define business assets and resources, securely exposing these resources as RESTful APIs, allowing 3rd party developers to access these resources, enabling all parts of the enterprise to be more agile and nimble in meeting the demands of the ever increasing global and mobile economy.”

How APIs impact your business plans

To date, many business plans and strategies that call for multi-touchpoint, disruptive selling have been stymied by the poor track record and ROI of the commerce APIs that were supposed to enable them. This next generation of APIs, based on Level 3 REST, will finally allow technology vendors and developers to deliver on their original promise of making commerce data and processes available everywhere in a secure, consistent, and cost-effective way.

In turn, marketers will be able to develop and justify real, compelling business plans that take advantage of these APIs to reach new markets, platforms, devices, and customer experiences – faster and cheaper than ever before. As you plan out the future of your online business, make sure that you ask tough questions of your technology providers, and learn how to recognize the APIs that will have a positive impact on your costs, scalability, and time to market. 

David Chiu

Published 29 March, 2012 by David Chiu

David Chiu is the digital commerce strategist at Elastic Path and a contributor to Econsultancy.

4 more posts from this author

Comments (5)

Avatar-blank-50x50

Deri Jones, CEO at SciVisum.co.uk

I've seen a few APIs over the last year, and I think the reason most if them didn't get much traction - is down to the classic problem of Marketing and technology guys not talking the same language.

In some cases, the data served by the API no longer even matches that delivered by the main website!

Here's how it typically goes:
* Business decides strategically they want partners to use their data/resources - so a plan for an API is kicked off.
* Business writes a business case and a spec for it - but there is no detail and precision of how the API will be used: it is assumed that 'IT will now how to build it'
* IT build and role out some API, they have questions now and again, but no one in the Business team really is confident to give good answers
* IT make all the API decisions, what to offer and how. The whole 'usability' issue never gets planned or discussed
* IT are under time pressure with so many projects, so they take the sensible route, and put up an API that is the quickest, least work
* result, the API is not nice + usable enough to get much traction in the market.

Of all projects that are kicked off by the Business - API is probably the one where they have least idea of what they want, what a good quality outcome looks like! So no wonder IT don't build a good one!

Are the Business willing to put resources /time to having (someone technica) write a good spec before they say GO?!

over 4 years ago

Avatar-blank-50x50

Steven Willmott

Great article - these challenges are definitely real, both in terms of articulating the business value of an API and in terms of getting it simple enough to use - exposing your entire backend system is generally not the way to go.

I work at 3scale (http://www.3scale.net) and we see a great many API launching and in progress and I'd say the vast majority have good engagement from both business and technology. Further there are new factors driving API design like the tools available being better (tools like ours but also within programming stacks themselves) that have a standardizing effect and also drivers like Mobile being an imperative for many companies to put an API in place.

None of this makes it an easy endeavor but we see more and more companies thinking about the functionality for their API first and layering their web site, mobile apps etc. on top of this core. It's still early but I suspect the value of doing that will only grow over time.

over 4 years ago

Avatar-blank-50x50

Deri Jones, CEO at SciVisum.co.uk

Hi Steve

3scale sounds like it's spot on for API management.

One question - it says it's not a proxy, so users can't offload to you handling large API traffic. It still goes through their own infrastructure.

In which case, am I right in thinking users need to modify their API code to 'talk back' to 3scale to log calls, or to authenticate them?

You say your clients are fully engaged business + technology teams - I wonder what your typical client looks like? Maybe if they're paying good money they take it more seriously than an inhouse API project?

Is the ability to outsource the authentication and logging of API usage the main driver would you say ?

Deri

over 4 years ago

David Chiu

David Chiu, Digital Commerce Strategist at Elastic Path Software

Thanks for the great feedback.

We are definitely seeing the emergence of an "API first" or "the API is your product" philosophy, where every user experience, including conventional ones like the website, are simply consumers of API functionality. IMHO this is the way to go.

At Elastic Path (http://www.elasticpath.com) we are transforming our whole platform to revolve around our next generation API. The old way of baking any kind of front end logic into the enterprise software is simply not scalable or sustainable for the way our customers want to do business.

A great example of this is Rovi, one of our key customers and a great partner of ours. Today on Econsultancy (http://econsultancy.com/us/blog/9305-q-a-rovi-s-david-jordan-on-the-future-of-digital-entertainment) they talk about the future of their business, and this sort of business absolutely requires a great API strategy.

over 4 years ago

Dmitry Sotnikov

Dmitry Sotnikov, VP, Cloud at WSO2

Great article indeed. APIs need to be carefully designed and probably even more importantly well *managed*.

For design, I would recommend that you start simple. Figure out what the main capabilities are that your own engineers and partners would need, and start with the very core.

Even better, prototype the first draft of the API first (e.g. in our WSO2 API Cloud: http://wso2.com/cloud/api-cloud/ - we have the capability to quickly prototype a simple API via JavaScript stubs, collect feedback, and then substitute the prototype with real API), collect feedback, iterate, release the API, start gradually adding new capabilities.

From management perspective, make sure that besides the API you actually roll out a convenient developer portal, which has pages for each API / method / resource, lets visitors try the APIs, has tons of documentation and examples, manages subscriptions, does OAuth key provisioning, has feedback forms and forums, gives you statistics on API usage and so on.

almost 2 years ago

Comment
No-profile-pic
Save or Cancel
Daily_pulse_signup_wide

Enjoying this article?

Get more just like this, delivered to your inbox.

Keep up to date with the latest analysis, inspiration and learning from the Econsultancy blog with our free Daily Pulse newsletter. Each weekday, you ll receive a hand-picked digest of the latest and greatest articles, as well as snippets of new market data, best practice guides and trends research.