Gluecon 2010 Intro Video from Digital Alchemy on Vimeo.

 After watching the Lakers finish off the Sun's, I’ve found downtime to reflect on a good conference, Gluecon. There were plenty of tracks for geeking out to and so much schwag in the bag that I was able to tattoo my notebook with my favorite stickers (still looking for a free Ubuntu sticker for my dual boot). It was certainly an event that was focused to a core audience of developers. There were a few things that I came away with; the proliferation of API’s and the disconnect that seemingly exists between the IT/engineering teams and the business. Why else would there be a session ‘5 Things I Hate about your API-TOS’?

This week I am attending GlueCon, a conference devoted solely to solving web-application integration. The agenda looks pretty interesting from both techincal and business perspectives. I'll be attending most of the architecture sessions and posting my notes here. If you couldn't be here and want to follow the discussions real-time, the hash is #gluecon and I'll be tweeting from Apigent on twitter

What is keeping developers from using your data?

You've taken the time to develop and expose API elements externally. You have thought of how you are going to manage communication by developers. You have prepared your business for an influx of ideas involving your data. You have thought of everything....but yet, developers aren't touching your API. Why?

Do you have a FAQ about your API readily available? FAQ's aren't glamorous and in most occasions, may not be that important. However, when it comes to developers using your API information, it is huge.

1. Make sure you have a FAQ available that describes each piece of data you are exposing.

2. Update your FAQ with answers to questions you receieve.

3. Keep your FAQ's up to date.

Analysis of our customers has shown that a robust, updated FAQ section increases developer use dramatically. Do not forget about your FAQ's.

When you make the decision to expose your data via API access to developers, you are going to have to be ready for a change in your thinking and psychology.

You have to realize that, for a lack of a better phrase, "developers want to mess with your stuff". They want to take your data and do things that you may never have thought of with it.

In order to make your relationship with these developers, you need to embrace a psychology of openness and accepting new ideas.

You also have to embrace a new audience...developers.

An effective API strategy encompasses knowing your customers (developers) and what they want to see and making yourself open to their feedback.

We just engaged with a large customer about their API usage, implementation, and strategy and there were some fascinating takeaways. This company saw the same issues that other smaller and medium sized businesses see with their API management.  It isn't the technological expertise or time needed to create their API content.

The issue is 2 fold:

1. "Once we have content out there, how do I explain to someone how we will monetize this?"

• A monitization strategy is key to not only keep momentum going but acquire future resources in your company to develop future API's and innovate the ones you have now.
  • The key is to establish clear metrics on what your API will deliver and what it will not and measure against that. Are you measuring audience, # of developers, API traffic, community traffic, etc?
• Also, you need to be able to fully communicate what your plan is for maintaining a successsful API community and tap into your external developers using your API's.
  • The best innovation for your overall product can come from a larger network of developers taking your data and using it in ways you never thought of. You are essentially receiving free innovation.

2. "How do we manage handling our API strategy moving forward?"

Monitoring cloud performance is different from on premise application servers. For starters, you can’t put a SNMP agent up there; can’t monitor WMI classes either. Shoot, you may not even have an IP address. So how would you monitor cloud applications? Here are three ways: