Yin and Yang of APIs and the Cloud - Part 2 »

In a recent post I talked about how you need APIs as your business grows; how services need to integrate directly to a companies' business processes through APIs rather than indirectly through a portal or Web site. Check it out here.

This time, because APIs need to scale, I talk about how you need the Cloud to effectively manage those APIs and enable developers to be successful using your APIs to build their apps.

You need a cloud to effectively manage your APIs.

Let's start by comparing API usage in the traditional enterprise scenario with API usage in the growing API economy around social and mobile applications.

In a traditional enterprise model it takes years to build out the enterprise ecosystem of apps and the life span of an app is often measured in decades. Traditional enterprise apps connected to back-end systems are typically designed to carefully shrink and grow their IT capacity. Change is slow, IT requirements are predictable but capacity needs to be available to support maximum loads.

In the new API economy - in a world of mobile and social apps development - we're working in an environment of rapid innovation and a usage model in which we cannot predict or preconfigure capacity. IT needs are not as predictable as in the traditional model. Burstiness or spikes in requests happen as a result of a number of things: API access and usage changes from within apps, app users come and go, apps can get popular for a few weeks, create a surge in demand, then subside.  It's a rapidly changing environment in which you need to be able to scale and respond to rapid bursts of requests that create periods of peak system usage.

Hosting your APIs in the cloud offers the ability to provision and deprovision as needed. In other words, you can avoid spending at the peak rate - rather spend at an average rate and take advantage of cloud elasticity and burst as required in times of peak load. Several enterprise API customers already leverage the Cloud for variable capacity.

Should the cloud be internal or external to your business? Inside or outside your firewall?

Unless your app developers and the APIs they leverage are entirely within the walls of your enterprise, I recommend that your APIs are hosted in a cloud outside your firewall. There are a few reasons:

- The developers who will use your APIs - your audience -  are external to your enterprise and supporting these developers is priority.

- Those developers are familiar with using public APIs. Developers are busy building social and mobile apps meaning that they're comfortable in an environment in which they connect to public APIs offered by Facebook, Twitter, Twilio, SimpleGeo, and so on. 

- It is common for developers to use more than one provider's API in building their apps. If APIs are behind your firewall, you make it more difficult for developers to access those APIs as they need to navigate different firewalls and different back-end systems for the different APIs they want to use. This will adversely impact developer adoption of your APIs. 

In summary, you need a Cloud to be able to scale and respond to the dynamic nature of today's API-driven apps. The Cloud should be on the Web outside your enterprise firewall to effectively support your customers - app developers.

Yin and Yang of APIs and the Cloud »

Cloud services need APIs. APIs need clouds. They are Yin and Yang. If you are working with one, you are working with the other.

First the Yin – if you have a cloud why you need APIs?

One of the ways cloud services (IaaS, PaaS, or SaaS) achieve scale is through customer self-service.

This usually means a customer portal, through which early customers – usually small companies or a department of a larger company – set up and manage their service.

At this scale, “integration” is achieved through people using the portal to interact with the cloud service, which in turn,  ‘integrates’ into the business process.

At some point, the use of the cloud service grows to serve larger companies or a larger cross-section of a company, or both. Now, “people-level” integration through a portal is not enough -  the cloud service must plug in or integrate directly to the companies business process.

At this point, you need an API. 

Tim Madewell from Innotas, a leading provider of SaaS PPM (project portfolio management) services makes this point well.

“In the early days of our company, our average customer had 25-30 users.  But as we started to grow and the SaaS market became more mature, we started working with larger enterprise customers and the product needed to evolve.  When we landed our first 5000-user account, we found that one of many requirements was that we enable integration from their back-end CRM, HR, and billing system.  Exposing the API where the customers can ‘come and get it’ worked well for large customers.”

The transformation that Tim talks about is the change from “here is a web portal that you can use to govern your IT processes,” to “here are the set of entities that we manage, and now you can interact with them in the flow of your processes.”  This is the transformation that is leading thousands of non-cloud enterprises to move from “here is a web site where you can deal with us” to “here are the APIs and now you can work with us.”

This is a big shift for the enterprises, and a big shift for the cloud SaaS providers.  A similar shift is happening to the IaaS and PaaS providers. An example is GoGrid's cloud control APIs where an enterprise can manage cloud provided computing and storage resources in the same seamless fashion as managing their own, internal IT-provided resources.

At IBM, we used to say that hybrid cloud management is a critical future need and that integration will become a big challenge with the proliferation of clouds (see my post).

I did not realize then was that this requires clean (hopefully REST-based APIs) on the cloud provider side.  I also did not fully realize that this requirement extends all the way into the IaaS, PaaS, and SaaS layers.  Companies like Innotas have taught me that indeed, the cloud, like other enterprise systems and applications, needs APIs.

Next, the Yang. I will discuss how all APIs need to scale, and therefore need the cloud to be effectively managed. Check out Part 2.

API Business Models and Monetization »

Even with the success of APIs like Twitter, Amazon and Facebook, it can still be a struggle to articulate the value of opening an API to execs and other business folks whose support is needed. (Maybe this is why so many APIs are launched as skunkworks projects.) But we can start by identifying the business model.  Common ones with open APIs are:
 
APIs as a marketing channel

Kipp Bodnar argues than any CMO should consider an API to extend brand awareness and consumers’ perception by letting developers write applications to distribute your content. And this might be at a fraction of your online marketing budget. To measure ROI, you could start by looking at the number of interactions you are getting through APIs or by tracking the traffic boost to your website.  
 
APIs as distribution channel for your content

If your company has some valuable content or data, APIs are a natural way to increase syndication. Indeed data accessible through APIs is easy to retrieve and can be embedded in other websites and applications. Many consumer web products, such as Google's many search API products, use this effectively to distribute content all over the web, which in turn drives their main advertising business model.
 
APIs are the cheapest and fastest way to build applications

You would love to build applications on all the different platforms your customers use - iPhone, Blackberry, Pre, Facebook, MySpace..the list goes on.  While it may never be possible to cover every platform, with an open API developers can help you create applications much faster than your team might.  For example, Twitter has no shortage of apps for every platform. 
 
APIs to distribute services

SaaS companies often use an API to distribute additional services. Your API could be either free because it's part of their existing subscription (a great way to differentiate service from competitors) or as an 'add-on' service for incremental revenue. SpinVox Announced last week 600 Registrations for SpinVox API which converts voice to text. They charge 35c for a 30 second message. Apparently their pricing did not discourage developers.
 
APIs to let third-parties extend your product

The same way than you would not be able to build all type of clients for different platforms, you might not be able to build specialized solutions for each market segment and vertical. By opening APIs you might create an ecosystem of partners and developers that augment your core offering with specialized solutions and innovative ideas. This makes your offering much stronger for your customers. Saleforce does this well - Force.com and the App Exchange cover a rich spectrum of specialized solutions they might not be able to provide otherwise.
 
APIs make your business more sticky

There is no secret than in the enterprise industry software integration projects are expensive and once in place, integration code rarely changes. SaaS vendors and services providers that managed to get deeply integrated in their customers IT stack tend to stick. 
 
So, what is your API business model?

Up next:  Roadmap and technical considerations for API monetization.

Case Study: SaaS API Governance and Management »

Last week, Tim Madewell of Innotas gave a great case study presentation on SaaS API Governance and Management at the Burton Group Catalyst conference.

The key point:  If you provide or use a SaaS API, you have to make sure your SaaS API has the same level of governance as on-premise alternatives.  And if you can nail this - you might have a significant competitive advantage over both your on-premise and SaaS competitors in your vertical.

Tim talks about the evolution of their API becoming an critical part of the service, the importance of governance, and how they operationalized their API.   

SaaS API management and operations »

This week we'll be at the O'Reilly Velocity conference on scalability and operations in San Jose.   On the topic of API operations, below is a case study we did with Tim Madewell of Innotas, providers of on-demand IT Governance -  where he talks about how they operationalize and scale their SaaS API.

Tim talks about the importance of having separation and visibility between front-end and back-end service traffic.  We are seeing this use case more often as more web products are being built off the same API that is opened to customers and partners.  Because your web app is the biggest customer of the API, it's critical to be able to understand and throttle traffic into the back-end to make sure your web app performance isn't compromised by API usage by other clients. 

From a competitive standpoint, Tim makes a great point that it's critical to be able to assure enterprise customers that a SaaS API is as robust as anything their customer could build or buy on-premise - not only from a functional standpoint, but operationally in terms of security, compliance, control and scale.   

For more on this, Dana Gardner did a great podcast on Innotas API management at briefingsdirect.com