Darwin’s Finches, 20th Century Business, and APIs: Evolve Your Business Model »

What do APIs have in comon with Darwin's observations on evolution, the 20th century garment district, and the Kobayashi Maru?

Sam Ramji makes the case for APIs in his much written about web 2.0 talk  - watch and listen to the full talk or just flip through the slides - both below.

Working over vendors:  A buyers guide for API management »

The explosion of APIs is driving companies large and small to launch APIs for their customers and partners.  But both public and private APIs require management features well beyond their internal functions.    How should you approach the 'build vs. buy' analysis and evaluating API management solutions and vendors?

As a former CTO that has recently gone through this process, here are some lessons learned on how to scope out requirements, evaluate and select a solution.

Know the problem (and requirements) you are solving for

Many API product managers are initially tasked to spec out only a small slice of the problem (such as "get me a developer portal"  or "we need developer analytics."  ) Your requirements landscape is likely much wider than this.  Make sure your PM thinks about business requirements that have technology implications in areas such as:

1.    Security, Access Control - Authentication methods
2.    Reporting, Analytics -Usage by developer, organization, API, location
3.    Threat Protection - Denial of service attacks
4.    Traffic Management - Routing needs for versioning, operations management
5.    Mediation, translation - Protocol bridge between SOAP, REST, JMS etc
6.    Performance, Scale -     Clustering, caching
7.    Developer support-     Access key management, FAQs, wiki
8.    Operational support - Root cause analysis, logging

(For more on these topics, see this blog series)

Get everyone involved, early.

Because APIs touch partner relationships, they are critical to the business, and there are multiple stakeholders in your organization.  Walk through the lifecycle of an API, what roles support the release of an API, external access, operational support and management. These stakeholders should be represented in the overall product management strategy and accounted for in your requirements for API management.

Considering a vendor? Demand a POC!

The requirements, operational view and deployment strategy will provide an outline of scope for build vs. buy considerations. All of these functions should be outside of the core elements of the APIs themselves to ensure consistency without duplicating efforts for key policy areas that are needed for your APIs.

If you engage an API management technology vendor, these requirements can be prioritized and used to drive a demo of a solution to ensure the capabilities meet your needs. Insist on a POC (proof of concept) for a deeper dive and validation of more technical requirements.  This exercise will quickly allow you to determine commercial solutions that have the potential to meet your needs and provide a concrete plan for demonstrating capabilities that are of material value to your organization.

A POC will tell you a lot about a vendor -  both what they would be like to work with on a day by day basis and how they meet their commitments.  A POC will also tell you how well your own team has thought out what they need and how prepared they are to execute it.    Eliminate vendors that will not step up to a POC.

Also,  make sure your own team goes back and can repro the POC -  without the vendor.     

This diagram below (and a larger version here)  shows how we thought about our POC process.

Revisit the priorities and rollout strategy for API management

This evaluation process should expedite the short list of vendor options that will satisfy your needs and as well as gain internal consensus on what API management means to your organization. You may find the depth and breadth of your requirements will motivate you to find a commercial solution rather than build your own system that will have to be maintained in addition to your core APIs.  

A key consideration for the solution you select is handing ongoing changes after this system is deployed. Once your APIs are operational you’ll need a way to manage updates to numerous policy areas on a regular basis and most likely you will want to avoid any downtime to implement those changes.   For example, my previous role, we did an cost analysis of how many independent API codebase versions we could support at one time.  Our answer?   Two.   This drove us to select an API management technology to  provide a versioning and mediation layer above the API layer.

It is important to review the flexibility of the system to avoid limiting your API management capabilities and practices to a particular solution.

Operational awareness

Policy enforcement is typically the initial area focus for API management but operational visibility is also a key area to focus to include as well. How will you report on usage and do you have a consistent way to collect data to be aggregated? Do you have a common root cause analysis process to enable message level tracing and logging regardless of the API?

Conclusion

The topics around API management are numerous and not unlike the questions that were contemplated during web browser adoption. With a new delivery model of information and services there are multiple stakeholders to consider during a ongoing lifecycle of development and operations.  Developing an understanding of your needs up front will greatly streamline your selection process as well as get a common understanding of what API management entails within your organization.

Don’t try to market to developers.  Instead, solve their problems. »

Not long ago you could count the number of 'developer marketing' programs on one hand.  Now there are hundreds of programs as Web companies and enterprises open APIs.   These companies know that developer adoption will make their API strategy succeed or fail.

But Developer Marketing is an oxymoron.  Developers hate marketing.   

You cannot drive adoption by 'marketing to developers.'  Sure, you can send offers to your developers but your mileage may vary.

A better formula - understand what's important to developers and give them what they need to reach these goals. Developers want to:

•  build new skills that lead to the best projects and jobs.  This is why new or proprietary tools and programming models are tough to get off the ground - it's a small market of new projects for the developer.
•  increase their productivity.  With good tools and by connecting developers with decent resources and each other for help.  This is why sites like StackOverflow take off. 
•  be recognized for good work and see their products used.  Focus on showcasing their work, not your product.  It's not about you.
•  get paid.  Think App Store model, or affilate marketing networks.

Talk to the folks that made the big developer networks sucessful and you'll hear these points over and over. Some others:

• Developers are not buyers, but are very strong influencers.  There are superstars in the developer world - make them fans and that is the best marketing you'll ever get.
• You can't 'own' or 'use' developers because they have an account on your service.  Developers have lots of options and switching costs might be low from your API.
• Act on their feedback.  Developers are smart and listening and acting on their complaints and ideas is critical to your credibility.
• Developer communities are fragmented.  For example, there is no such thing as an "API developer', but instead there are Twitter or Facebook or Salesforce developers.

Once you have attracted a developer to use your service - they are like gold.   So treat them with respect - don't try to 'use' developers or you might lose them!