Why API as a Strategy

By Emile Kfouri
September 07, 2008

A compelling reason to build your product and its strategy around an API.


First, let’s start with a little quiz. I promise it won’t be too hard.

Question: What is common between AutoCAD, Microsoft Office, eBay, Amazon, Google, Adobe Photoshop, Microsoft Visual Studio 2008, Microsoft Windows Vista, Autodesk 3ds Max, LEGO MINDSTORMS and the Apple iPhone?

Answer: Let’s see. At first glance - software and hardware, OS and Web 2.0, developer tools and productivity applications. But they are also all market leaders in their field and they all have APIs (Application Programming Interface) that are used by many companies to build businesses and products on top of them. The value to third-party developers is to avoid recreating the functionality in the base product and as a result, simply focus on creating value-added functionality. Third-party developers also have an automatic installed base of millions to which to sell.

What is an API?

API stands for Application Programming Interface. In short, it is the equivalent of a Graphical User Interface (GUI) for programmers. Users interact with a program using the GUI, programs “interact” with other programs using the API.

APIs can run the gamut from simple access to application data to the ability to do anything that can be done through the GUI and more. If you do not have an API, the question is, do you need an API? Well, in many ways it is the entry ticket to the big leagues where the market- leading products play.

Within weeks of the original Lego Mindstorm debut, Kekao Proudfoot reverse engineered the RCX brick (hardware) and posted his findings online. Other engineers then used his findings to create Mindstorm tools, including an operating system and a C-like programming language. Lego had the ability to stop them but instead decided to let this community flourish. 'We came to understand that this is a great way to make the product more exciting,' Lego’s Nipper said.
From Geeks in Toyland By Brendan I. Koerner - Wired Magazine February 2006.

In the case of the LEGO MINDSTORMS, it got an API completely by accident (someone hacked into the hardware). The result was a tremendous growth in that market because now their product was no longer just for kids. In fact, a large portion of the people who bought it were adults who wanted an easy way to play with robots. (And tell me, who among us did not have a childhood dream of creating their own do-good or evil robot?)

Why an API?

There are many advantages to having an API including:

  • Scaling Development

  • Converting Competitors Into Partners

  • Scaling Market Reach

  • Empowering Users

Scaling Development
The API provides a way to add and enhance a program without having to get into the guts of the program itself. An API allows groups of developers (internal, partners or contract developers) anywhere in the world to enhance the product with minimal coordination. The advantages go beyond better architecture of the program’s source code because API users are actually completely shielded from the program’s internal source code. This in turn provides the opportunity to add value to your product outside of your regular development cycle. Interestingly, users who develop or purchase products that work on the API-based application are more reluctant to try alternatives because of the investment users have made in the product.

Converting Competitors Into Partners
It is clear that partnerships can make companies stronger by developing synergies between products and cross-selling to each other’s existing clientele. The API can help turn your competitors into partners by allowing them to build solutions on top of your product’s functionality. This concept lets partners leverage the existing capabilities of your program and enhance it by using their expertise and know-how to create new and innovative solutions. This approach sure beats duplicating the functionality of your base product first. In return, they can get access to your user base or open up new markets for you with less investment in software development from either side.

A few years ago, the Autodesk Revit product design team was doing a workflow analysis to see where users were wasting the most amount of time. They noticed that printing large drawings was taking a lot of time and had many problems. When the team assessed the problem, they realized that even the simplest solution could not be completed in time for the current release and waiting for the subsequent release was unacceptable. They decided to expose a few new APIs related to printing and create an Add-in using the Revit API. It was made available in between the releases. The add-in quickly became one of the most popular add-in downloads for the product.

The API let the Revit team address a problem quickly and push value out to the users rather than making them wait for the next release. An interesting by-product of the new API was that three different companies used the same API to create their own products too, building more value on top of Revit.

Scaling Market Reach
As you have probably figured out, the API lets one build on top of a product and expands its capabilities. An API opens up the opportunity for ways to tap into markets and geographies you would not otherwise have the resources or expertise to get into. The ability to have your product “countrified” with not just translation but also with features and content relevant to that market can be a very compelling offering in a new market. An API offers the possibility of creating or modifying features to suit specific markets and it can also help automate the creation of content relevant to your market.

Empowering Users
Simply put, an API empowers end-users by making their product do things the original developers did not build into the product. It also lets users customize the product to better fit their needs and workflow. The real secret is to create features and APIs that are not dead ends, but rather extensible solutions used to solve more specific or specialized problems with just a little bit of effort (this is sometimes called the Final Mile problem).

Page 1 / 3

About the Authors

  • Emile E. Kfouri is the AEC Solutions Sr. Platform Line Manager at Autodesk Inc. He has 15 years experience in software development and product management with a strong interest in how technology and APIs can help support the long term business objectives of organizations. Emile can be contacted at apiemile@humanscape.com

Post a Comment


Allowed HTML: <b>, <i>, <u>