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.

Don't over architect your application integrations!

Simple and agile should be your foremost design considerations in integration. Trying to get applications with different functionality and schemas to talk to each other via different protocols or APIs is complicated  enough, you don't need to add to it. Focus on the business reason why you're integrating the applications. If in doubt, ask your business user or CIO.

Keep these guidelines in mind as you embark on your next integration project:

• If point-to-point works and its all you need, don't spend time and effort designing a hub-n-spoke model and an all encompassing uber canonical intermediary model. Unless you're the fortune 100 (50?) and have multiple identical applications across your enterprise, most of your integrations will be point-to-point. That's true even if you force a messaging bus (queue) in the middle. Don't confuse your underlying software/hardware architecture with your actual integration architecture. Everything may flow through a single hub (or server) but you can still just have a bunch of point-to-point integrations. If object A from application A only needs to be integrated with object A of application B, then stop there. If you have an integration platform worth it's salt, you can always come back and evolve your integrations.
  

• Avoid custom code like your job depends on it, which it will. Custom code is the path to the dark side and the famous Gartner Spaghetti diagram. It's not point-to-point integration that gets you in trouble, it's the lack of a unifying integration platform that leads to Spaghetti. Using an integration platform will give you consistency across design and management of your integrations. If you're being tempted by the dark side to use custom code, remember that running tail on a log file doesn't consitute management and monitoring. If you're getting tempted to build your own awesome integration platform, go back to your business user or CIO and ask them what they wanted again.
  

When selecting off-the-shelf integration software, keep the following in mind:

• Pick an integration platform that can deliver 80% of what you need out-of-the-box. Most enterprise application integration problems fall into the 80% category. The other 20% edge cases may need a different solution. Platforms and vendors that focus on those edge cases to differentiate themselves tend to provide the same model for solving all problems, with great pain and difficulty!
  
• Make sure what ever solution you choose has solid coverage for the 3 basic types of application integration:

• Data Synchronization - One time migrations or ongoing synchronizations.
  
• Process Integration - Data syncs only get you so far, being able to write integration flow logic tying different business processes together is also important.
  
• UI Integration (aka Mashups) - Perhaps the most under rated method of integrating applications. If all you need is visibility to data in another system, why synchronize the data. If you don't need to use the data in the target application for processing or reporting, then don't synchronize it. Most applications these days provide browser-based interfaces with the ability to embed iframes or other methods of incorporating external data sources. "... mashups can deliver an 80% solution at 20% the cost (or less) " (source: http://blog.programmableweb.com/2009/07/23/enterprise-mashups-continue-to-gain-momentum-as-part-of-enterprise-20/).
  

• Apply standards when they make sense and avoid them when they only serve to complicate solutions. Having adopted SOA doesn't mean that every thing needs to be exposed as a service. It certainly doesn't mean that you should force adoption of overly complicated WS* "standards". Stick with the basics that you really need (vs what would be cool). You'll find varying levels of WS* "standards" adoption in the application market place. SOAP-based or REST-ful? What ever works. You'll find that you'll have to be able to support all kinds of different "standards". Make sure your integration platform is flexible.