API Trends: What to expect in 2012 »

Thanks to all who participated in last week's webinar:  "API Trends: What to expect in 2012" with Sam @sramji, Anant @jhingran, and Brian @brianpagno.

Here are the video and slides. Thanks for a great interactive session.

We'd love to hear more of your thoughts and questions; please join the conversation on the api-craft forum.

“Mobile APIs - Optimizing APIs for many devices” Webinar - video & slides »

Thanks to all who participated in yesterday's webinar - " Optimizing APIs for Many Devices"  with Sam @sramji, Brian @brianpagno, and Greg @gbrail.

Here are the video and slides. We'd love to hear more of your thoughts and questions; please join the conversation on the api-craft forum.

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.

“Bigger, Better Business with OAuth” API strategy webinar - video & slides »

Thanks to all that attended yesterday's webinar "Bigger, Better Business with OAuth."  

Unfortunately, we had a Webex outage which cut the webinar audio off after a few minutes, but thanks to @sramji and @landlessness for finishing out the webinar for the video (and slides below) after the outage.

Video and Slides - “Developer segmentation for your API”  strategy webinar »

Thanks to all that attended last week's API strategy webinar "Developer Segmentation for your API" on developer community and market size. (And thanks to our speakers @sramji  and @landlessness).

Here are the video and slides (and as always, you are free to use under Creative Commons).

“Your API is not a website!” - webinar video and slides »

Thanks to those that joined us for last week's API how to webinar presentation "Your API is not a website".   (and thanks to our speakers @gbrail and @brianpagano)

Video and slides are below!

Video and Slides - “Boss, we need an API!”  strategy webinar »

Thanks to all that attended last week's API strategy webinar "Boss, we need an API". (And thanks to our speakers @sramji, @brianpagano, and @landlessness).

Here are the video and slides (and as always, you are free to use under Creative Commons).

Join us this Thursday for our next API webinar "Your API is not a website!" by @gbrail - you can sign up here!

Video and Slides: Is your API naked?  API Platform and Ops Considerations »

Thanks to all that attended last week's API Best Practices Webinar #5 "Is your API Naked? API Platform and Operations Considerations" (and thanks to our presenters @gbrail and @landlessness). Video and slides are below.

Our next API webinar, "Your API Sucks!  Why developers hang up and how to stop that" with @landlessness and @earth2marsh, is June 14th at 11am PST (sign up here!)

(And you can see all our API best practices webinars to date here)

Video and Slides: API Metrics - What to Measure »

Thanks to all that attended last week's API Best Practices Webinar #4, API Metrics - What to Measure (and thanks to our presenters @brianpagano and @landlessness). Video and slides are below.

Our next API webinar, "Is your API Naked? API Technology and Ops Considerations" with @landlessness and @gbrail, is June 14th at 11am PST (sign up here!)

Social Commerce as part of ‘Distributed Commerce’ through APIs »

There’s been some buzz about ‘social commerce’ this year, with a great WSJ article a couple weeks back: Retailers Embrace Social Commerce.

However, there’s not really such a thing as ‘social commerce’.

What these companies are doing is executing a ‘distributed commerce’ strategy.To really understand this profound shifft, it's worth watchign Sam Ramji's talk on  evolving business models in his Web 2.0 Strategy presentation: Darwin’s Finches, 20th Century Business and APIs.
 
A key point in this talk is how business is migrating from a direct to indirect model. 

The web revolution that gave birth to Amazon and eBay was based on a shift to a direct business model… retailers selling directly via their websites. 

Today businesses are figuring out how to execute an indirect model.  They are trying to put their product/service/content where their customers are. 

To use some retail-speak, the nuance is that commerce is now about more than about 'selling in' a channel, it is about selling ‘through’ a channel.

So where are customers?

Increasingly, consumers are on the move and on their smart phones.  They are on tablet computers like the iPad and on game consoles (xbox, ps3) and set-top boxes (roku, etc), and filling their car at gas stations. 

Consumers are also spending time on social networks… which brings us back to ‘social commerce’.

Borrowing Sam’s Finches metaphor, retailers are exploring their ‘niches’… reaching out into the places where customers are, and selling in that context.

So a Facebook store is just one niche, one place to reach customers where they are.   Gamestop is another retailer with a Facebook store.  However, Gamestop is also on mobile device apps and other social networks.  They are executing a distributed commerce strategy well.  In the same issue as the social commerce article, WSJ reported that Gamestop’s profit rose 6.9% on higher sales.

Another example of distributed commerce is Shopsavvy, a mobile app that searches for products based on location and brings back pricing, availability and product attributes.  Retailers want to be included in the shopsavvy app to have their products discovered by consumers in that venue.  Shopsavvy itself is exposing its engine to developers who are finding niches of consumers via wine-specific apps, “Lego apps”, etc

In the post-web world, forward-thinking retailers are executing distributed commerce strategies to reach consumers where they are, including on social networks. Where are your customers?  And what is your distributed commerce strategy to reach them?

Globalization, Black Swans, and APIs »

Sam Ramji gave this talk at GlueCon on delivering APIs globally.  Considerations include:

• distribute locally
• serve elastically
• specialize universally

To see what Sam is talking about (and how Black Swans play into it) check out the slides below.  To deliver APIs globally, also check out our API Delivery Network - a CDN for APIs. 

Video: RESTful API Design (Pragmatic, not Dogmatic) »

Recently Brian Mulloy (@landlessness) and Marsh Gardiner (@earth2marsh) hosted a webinar on API design and Pragmatic REST. The video of the recording and the slides are below.

Our next API webinar - 10 Patterns in Successful API Programs - is this Thursday, May 19th at 11am PST, with Brian and Greg Brail @gbrail. Interested in the topic? Then you should sign up now!

Mapping out your API Strategy: Webinar slides and recording »

Thanks to everyone that attended yesterday's API Strategy Workshop Webinar (and thanks to our presenters @sramji and @landlessness)

The slides are below and here is the full recorded webinar. 

Join our next API webinar, "Pragmatic REST:API Design Fu", May 5th at 11am PST.  You can sign up here. 

Free Webinar: Mapping Out Your API Strategy »

Ever need to explain why APIs are so powerful to someone at your company?  Need an easier way to think about the different API strategy options?

Join us for a Webinar - “Mapping Out Your API Strategy” - this Wednesday, April 20 at 11 am PST / 2 pm EST.

It's free (of course) and you can sign up at this registration page.

Brian Mulloy and Sam Ramji will talk about the API market, and propose some ways of thinking (and cool frameworks) for how you can think about API strategy vs. your objectives.  

Punctuated Equilibrium, Celestial Navigation, and APIs - Web 2.0 2011 API Strategy talk »

Sam Ramji from Apigee, along with Dan Jacobson and Michael Hart from Netflix, recently gave this API strategy talk at the Web 2.0 Expo in San Francisco. 

It includes frameworks, best practices and lessons learned to help in thinking of your API strategy from a business model, architecture, and data perspective.   

Why Punctuated Equilibrium and Celestial Navigation? See the slides below and look out for the full video shortly. 

Using your existing systems to create new value with APIs »

Companies need to wring value out of their investments; find new ways to serve customers or create new value with their current systems, products, supply chains and partnerships. 

I keep going back to water analogies.  My house has a plumbing infrastructure that was paid for a long time ago.  I recently found new value in that infrastructure, an automatic sprinkler system.  Again the system reminds me of an API.  Through this one common interface I can connect many endpoints (sprinkler heads) and my yard has never looked better.  I have some endpoints that cover the lawn, some that concentrate on shrubs, others take care of the plant beds.  The point is that I tapped in to my existing water pipes and found new value in a 35 year old system. 

Can you do the same with your enterprise systems?

Let's take a common strategy like a mobile device strategy.  First we have to understand what information customers need when using a mobile device like a smartphone.  Certainly location and product come to mind.  Maybe information about their account or orders.  These little gems of information can be exposed through the API interface and carried to many different endpoints; today a smartphone, tomorrow a tablet PC or connected car.  Let's call these 'functional APIs" since they carry a function to the user through a mobile device. 

The next step to realizing a functional API is to map the data elements and functionality of the new API to their location in the existing systems.  These data elements may map to databases, ERP systems, other internal services, etc.  In fact, a single API may map to one or more internal systems.  Any holes that are discovered will have to be filled. 

For example, if you are designing an API and define features or data that aren't available through existing systems, you will have to provide that new system or new data set.  But, in the interest of embracing the legacy systems, you should be able to reuse the majority of what you have by extending it outward through the new abstract API.

Leveraging what you have through an API can reduce your development cost, give you speed to market and also give you more flexibility in the future to integrate with more devices and partners.  Leveraging my existing residential water system yielded a "yard of the month" award, perhaps this strategy can beautify your business as well.

Next we'll talk about the details of integrating with existing systems.   And ots on this in our recent whitepaper "APIs: A Profit Interface - using APIs to grow your business.

What’s an API?  It’s Money, Baby! »

So I'm on my magical patio again consuming a cold beer and thinking about retail customers and the systems that serve them.

I've been asked too many times in my career to replace legacy systems with bright shinny new retail systems. Now, I'm a bit of a nostalgic guy. My first rule of technology is "embrace the legacy". Good thing because not only has that saved millions of dollars for the companies I've worked for, it's also made them millions of dollars.  

You see, I've found that the fastest path to innovation is through understanding the past; the solutions to even the hardest problems are always obvious with hindsight. Irony at its best. You don't need to see into the future, you need to see into the past.

Freedom to Innovate
With that in mind, you can free yourself from the excuses of not innovating. You won't need millions of dollars in new systems, a hoard of new employees or a 18 month roadmap to change the way you do business in the new multichannel web. Want to reach mobile phones, app stores, set-top boxes, hoards of partners and affiliates? All you need is a way to tap into all the goodness of your enterprise systems and capabilities. All you need is an API, or as I call it, A Profit Interface.

That's the first step - abstract yourself from the legacy systems with an API - technically an Application Programming Interface (a technology blast from the past). Abstracting from the legacy is a bit like asking a girl to drive you to the prom but not making her your official date. You want to play the field and in this age of retailing that means smartphones, tablets, e-book readers, kiosks, game platforms, connected cars and internet everywhere. APIs let you get there.

Getting Everywhere, Fast
Imagine having a single connector, to say your legacy product catalog, that all those new screens could access quickly.  And when the next sensational device arrives, you just snap it in - no coding necessary. How many more sales could you make if your customers had access to your products and services from anywhere?  What if another retailer could access your product catalog and offer your complementary items to their customers? That's money, baby!

I know because the innovations I've seen and guided at companies opening APIs have made millions of dollars. I even got a couple of logo coffee cups for my efforts. One more beer, slides into my logo beer cozy. I forgot i got a cozy too.

I really wish I could pay for all this beer with my phone. I always forget my wallet in the car. Hmmmmm..... how to do that without millions of dollars in hardware upgrades? Maybe someone needs to contact the beer distributors about embracing their legacy systems...

Where will your customers be this Christmas? »

Keith Morrow has a great article on TechTarget series on how an API can create a disruptive impact on a retailer's ability to reach customers beyond traditional web browser channels.

One key point is that an API can be driven by a relatively small team. 

Yet an API has a disproportionate impact on the business, and this impact scales with low marginal costs.  

This can be an especially effective strategy for retailers that might live in world of thin margins, limited resources, and the constant pressure of the peak holiday season. 

For more on Keith's retail API experience, we commissioned him to write a Retail 2.0 API Strategy whitepaper discussing Retail API opportunities, challenges of launching with tight resources, and best practices.

You can download the whitepaper here.

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.

Paypal X: Open API as an Indirect Strategy »

On Tuesday, the WSJ ran this article about the launch of Paypal X, Paypal’s developer program.

Great to see an API showcased as the heart of an industry leader's core business strategy - and called out as such in the top business newspaper. 

Paypal is executing an indirect strategy by opening their core services via APIs in order to have their payment capabilities more easily consumed in other applications and services.

Ten years ago, you could read articles like this about companies launching their websites to execute a *direct* business strategy… selling directly to customers.

Just as it was a decade ago, companies will slowly wake up and realize that they need to have an indirect business strategy online, either because they see the massive business opportunity ahead of them, or they see their competitors already executing an indirect strategy against them.

We see 'indirect online strategies' like PayPal and TransUnion Interactive as the beginning of an emerging API Economy.   A company without an API in 2009 is like a company without a website in 1997.