Not building an API? You’re doing it wrong

“API” used to only be about header files and function definitions — you know, stuff only programmers cared about — but not so much anymore. Now your software’s API is becoming the make-or-break center piece of your technology strategy. We are discussing APIs with most of our forward-thinking customers even before we sort out the core functionality because for a growing number of companies, how their service integrates with others is core functionality. As users have become more social, so has the software they use. I don’t mean social as in sharing ironic photos of your breakfast, but rather social as in your users expect your service to work seamlessly with everything else they use, or they won’t use it at all.

Sure, making your software a platform and reusable isn’t a new idea. If you go back to prehistoric times, you may remember the hype around component-based systems such as Microsoft’s COM. COM was a nightmare for most programmers but did effectively lock a lot of businesses into Office. Then there’s the more recent hype around SOA. This is probably a term that causes physical discomfort in most developers, even if just because they’re tired of the buzzword itself. While what I’m talking about here is essentially SOA in concept, that word was too quickly hijacked by “enterprise” software vendors selling overly complex (and expensive) tools and standards that, while making them tons of money, also made simple things terribly hard.

So why is the hype around today’s APIs different? On the implementation side, we are talking about simple REST-based services that exchange JSON data. This technology choice quickly gained momentum because it was a developer-driven pragmatic solution and not forced upon us by software vendors or standards committees. This approach is so simple that even Java (which hasn’t gotten any web technology right, ever) couldn’t screw it up and now has a pretty decent REST solution with its JAX-RX spec. Also, if you are building a modern web UI, chances are you are already thinking in terms of AJAX APIs for your own internal needs, so opening that up to 3^rd parties for integration may only be a small incremental cost.

So developers are on board. But you’re probably asking, “Why, again, is this important to my business?” Some thoughts on why your API will be critical to your strategy:

• Expand your audience: Why limit your users and customers to only those who downloaded your app or are on your website? By allowing your service to surface in other people’s products, you can vastly increase your user base. If your business model supports it, your service can even serve as an additional revenue stream for your partners with little to no risk on their part.
• Do what Apple won’t let you: A lot of the action we’ve seen on the mobile side is around making apps (and their underlying services) work well together. Unfortunately for developers, mobile apps are in a sandbox so desktop-style interoperability isn’t possible. But if you expose your service as an API, you can work with 3^rd parties directly to get your service integrated with theirs. The good news is that once you forge these relationships, tight integration at this level can serve has a huge barrier to entry for your competitors and thus be a strong strategic advantage for you.
• Some ideas only make sense as part of an ecosystem: I’m thinking about services like Gravatar here. It doesn’t do much itself, but it’s now tied into nearly every online collaborative tool on the planet, and it is now emerging as a de facto single sign-on standard. Since it’s owned by the WordPress guys, it helps them weave their own services in with things that have nothing to do with blogging. That could be you too.

In short, while focusing on your API isn’t exactly new, it is the future (again).