Tuesday, March 30, 2010

Why is API development often an after thought?

For most application developers, SaaS and on-premise, this seems to be the case.

There probably isn't a company out there that runs their entire business on one single application from one single vendor. SAP and Oracle would probably like it to be otherwise but even they realize that it's a hard sell. SAP provides one of the better APIs in the 1.0 application space. A true sign of maturity. If your application offers any value to customers, then providing them with the ability to integrate it with other applications only serves to increase it's value not to mention it's stickiness. An integrated application is much harder to replace.

If you already have APIs or a method of integrating your applications, how would you rank it using the simple scale below?
  • Level -1: Our services or engineers can write custom code when needed to export/import data when necessary.
You're in trouble. You know it or not. How can you scale this model? How do you maintain all the custom code?
  • Level 0: Users can export or import a CSV file via a button or link in the application.
This is the bare minimum. Your users can manually import/export data and when ever they want to switch to your competitor, it will be easy for them. If you don't already have a way to get/post the file via HTTP(S), add it so you can at least automate the process.
  • Level 1: We have XML over HTTP APIs. 100s of different operations exposed. As far as a schema, we provide DTDs or you can use the query option to see what elements are available per object so you can manually construct your requests.
Congratulations! You have APIs and can tightly integrate your application with your customers. However, you are certainly putting all the burden on your customers to figure things out. Integrating with your application will cost users more and keeping up with changing requirements or application customizations will require significant effort. Don't be surprised if integration is still an area of concern for your customers and services team.
  • Level 2: We provide Web Services (WS SOAP or REST-ful). We have well defined WSDLs and/or schemas (XSDs, RELAX NG, ...). For every customization in the application, users simply re-download/import the WSDL (or schema). We release a new version of our APIs with every release which you need to immediately adopt.
You're well ahead of most of the market but don't bask in the glory too much. You still have work to do. While a static WSDL or Schema based approach seems easy enough, just ask a developer how much they enjoyed re-importing the schema 20 times because the users were making last minute changes. Consider moving your APIs to the next level.
  • Level 3: We provide meta-data driven APIs via Web Services (SOAP or REST). As users make customizations to the application, they simply have to retrieve the latest set of object meta-data to include any new or changed fields. As new versions are released, users need only upgrade if they want to take advantage of the new capabilities.

You clearly understand the value of APIs and have made it a priority. Thank you!

For those of you wondering who in the 2.0 application world has achieved level 3, take a look at Force.com's APIs. Their APIs are well documented and publicly accessible. Follow the leader!

If you're planning on building or re-building APIs, I suggest reading "The Top 10 Most Common API Pitfalls" too. I have a slightly different view on a few of the points which I'll post very soon.

In conclusion, you have to make API development a core feature and part of your strategy. It's critical to your success.