Posted by: asmitty | March 26, 2009

Why SaaS Companies Need VAR’s

Once you’ve established which side of the equation you are on, it’s time to evaluate partners. You may think that you have the capabilities to do everything in house, but the truth is that you have enough to do managing your backlog of enhancements. If you have a large organization, perhaps you could build everything in house, but why? That’s so, web 1.0.

If you are a content provider, you have probably already documented your technical requirements like API Key issuance, usage limits & throttling, and reporting. From a business perspective, you would like to have a community with forums, on-line documentation, etc. Those things are good baseline requirements, but remember, what is your business goal? Are you providing an API for clients to develop on? Are you prepared to manage a developer program? If your goal is to integrate your SaaS to existing (legacy) applications or other SaaS applications in the cloud, you still have more work to do.

If you are a systems integrator or API management vendor, what solutions are you providing your client? What are the gaps?

If a content provider wants to integrate with the top 3 CRM providers in the mid-market:, MS Dynamics CRM, and RightNow. Can you provide connectors for those endpoints as well as build a connector for my application? Can we put it in the cloud and monitor the amount of  data throughput of the integration? Maybe I want to provide tiered pricing to my clients based on anticipated volume, or SLO’s. And I want to bill the integration as a subscription, consistent with my business model.

Can you do that for me?

Posted by: asmitty | March 24, 2009

API is core to your integration strategy


If you provide, or have plans for exposing, a web service API, your primary focus is on providing integrations with your application or service and other applications. The problem is, the API in and of itself does not go far enough. There are business logic, endpoint mappings, and roll-ups that require the help of a programmer and application expert. Should you expect that your clients have access to these resources and can consume your API?

SaaS consumers are, generally speaking, small to midsize companies. Yes, I acknowledge that big players like are competing with Oracle in large accounts, but historically speaking, SaaS applications can find opportunities amongst smaller workgroups. One of the reasons for this is the TCO, but that is the subject for another post.

Those smaller companies usually do not have the time or resources to complete the task of integrating two systems via the API. Here is what Bob Warfield says on the matter:

“When you have a large IT group, you can afford to, and indeed, may even want to dedicate some of them to building the integrations.  When you have a small group, if the vendor can’t do it for you, it probably won’t ever get done.  So it isn’t that the little guys care more, they’re just helpless to get any kind of solution if they care at all.

What does this mean for SaaS vendors?  In this case, having out-of-the-box tight integration with other SaaS vendors (or On-premises packages) was a big differentiator.  It lowered the deal friction (less to worry about on the custom install side) and increased customer satisfaction (hey, we could never get these two systems to talk before!).”

This raises a question for you; what is your ultimate goal that you are trying to achieve with your API? Do you plan to supply content (water) or build integrations (faucets) to all the various endpoints that your clients will want integrations with? I use the analogy of water and water faucets to illustrate in very simple terms. As the supplier of content, you should be concerned that your water is clean, metered, and with some assurances of availability. That is enough to worry about. It is the system integrator, or faucet manufacturer that designs the correct interface for specific use cases.

Trying to be both can be frustrating, time consuming and expensive. If you know your market well enough, it could make business sense to “own” some integrations – QuickBooks is the GL application for over 80% of the small businesses out there so it would be prudent for some business managers to make this investment.

Examine your business model
Are you a supplier of content or are you in the integration business? How does this impact your API strategy? Do you have reporting of who your clients are and how much “water” they consume?

Posted by: asmitty | March 20, 2009

Show me the money

You remember that famous line, when Rod Tidwell had Jerry on the ropes, and Bob Sugar on hold? Remember what he said?

“Show me the money”

Yeah, well, being a Product Manager is a lot like being poor Jerry. The last thing you want to do is ask for funding for a project that has no target market or nebulous one at best. My process for getting approved for funding went something like this:

  • Build a business case for integrations between us [content provider] and two or more CRM’s.
  • Perform a technology assessment – we did not have the expertise to build the integrations ourselves.
  • Locate a systems integration partner.
  • Partner has requested access to API.

And so the story goes, the API was a means to an end. We did not position that a bunch of companies would come banging at our door to give us money for using the API (which they would still have to build a client facing application around).

Of those we did speak with, there was always a put and take involved. We provide some access to the API along with training/consultinig while the partner pays us on a % of revenue or a fixed rate [data] subscription. And each partner had a different business arrangement. That is why you need API management; to enforce the business rules that you have set up with your partners.

Why do you want an API?
1. Are you trying to integrate endpoint a to endpoint b?
2. Would you like to open up a developer channel for new business opportunities?

The truth is that, to those of us in business, API is really a buzzword. Sure, we think we know what it means. We try to create marketing campaigns around it. Data sheets for it. T-shirts to wear it. As Dave McClure pointed out, the API is for geeks. You’d better know how to market to THEM. As a business manager, our job is to make sure that we establish the rules and controls around the API.

Posted by: asmitty | March 19, 2009

Introducing asmitty 3.0

A friend contacted me the other day looking for information on API management alternatives to Mashery. I previously worked with this friend during the Hoover’s implementation of HAPI. I wondered if they were unhappy with the business relationship.

It turns out that this research was for another friend. “Why don’t you set up a conference call?” I quipped. No good, the other guy is out of the office for a week. We’ll figure something out.

A few days later I received an email from Mark, a former manager while at HP software. He wanted to connect me with Martin Tantow, co-founder of  3scale Solutions, a venture which he is associated with that does API management. Okay, I get it already; I need to share what I know for the benefit of others.

Over the next few days and weeks I’ll write about why we needed an API, the internal fears that we had to overcome, and the vendor selection process. I’ll write about my current API management problems, and how they really are not API management, rather integration challenges. All this is coming from a person that has listened to the pitches, attended the conferences, met the founders and used the services. I’ll share what I know and invite you to do the same.


I’m reading a lot of theories about why companies want an API. I want to talk about why I pursued an API for my previous employer – here’s a hint, it didn’t have much to do with Long Tail markets. The application of that theory would come later. Our immediate challenge had everything to do with commercial integrations with other [CRM] products.

Access Hoovers
I worked (still do) for Malcolm while we were at One of the major products he launched was an integration with Access Hoovers fueled the CRM with high quality business information. That wasn’t his value proposition, but that is what it accomplished. It was a top 10 download for years. The problem was, it was really a custom application that called some web service brokers but was really a lot of PHP. When we decided to extend to other CRM platforms, it was near impossible.

API vendor auditions
We were initially approached by StrikeIron who was already providing an API for our parent company D&B. I recall the executive briefing very clearly. All was going well until the moment that Jeff Guillot learned that StrikeIron would want to host our data and BE the API. From a technology perspective, it made sense; allowing StrikeIron to host the data, develop and manage the API would guarantee QoS and uptime. But legally and logistically, it would be a nightmare for Hoovers.

By allowing StrikeIron to be the API, they would guarantee QoS and up time. But legally and logistically, it would be a nightmare for Hoovers.

I approached Mashery in November of 2007 and when they said they were a SaaS infrastructure and Hoover’s would own our own API’s, I knew we had an opportunity. What I didn’t know was how much internal selling I would have to do. Content providers, like news companies, were afraid of opening API’s. They fear some new start-up, sucking all the data from our servers and cannibalizing our business.

Key learning’s:
1. Know exactly why you need an API. Are your goals in alignment with your API infrastructure provider?
2. Do your homework selling the need for an API internally. If not, it doesn’t matter that your provider can have your API business on line in a few days or weeks.

(Image by Rosalyn Metz)

« Newer Posts