The Role of VARs in SaaS

Aug 7, 2009 by Abe Sultan

I just got back from Las Vegas from having participated in a panel for CompTIA Breakaway 2009 where the focus of the panel was on the role that VARs can play in the SaaS space.

First I need to get something off my chest that has been boiling inside of me since my first few conversations with some of the attendees and VARs at the conference: Hosted Exchange or managed IIS servers is NOT SaaS, call it Managed Services, or whatever you want to call it but it certainly is NOT SaaS and certainly not PaaS for that matter.

Now with that out of the way ;) it doesn’t mean that VARs don’t have a role in SaaS and frankly the reason why most VARs use the term SaaS interchangeably with Managed Services is because they really can’t be bothered with the details that actually define SaaS; they simply care that you use it as you go and it lives outside of your premises. SaaS just happens to be today’s cool buzzword, so why not ride the wave, right?

Anyways, back to the point I wanted to talk about; VARs and Channel players are normally considered the Trusted Expert for their customers and as such they can still provide expertise on SaaS applications and arguably much easier than traditional on premises applications.

There are many ways that VARs can make money in SaaS and a lot of them, the same ways they make money today; here are just a few:

Commissions: Many SaaS vendors have referral programs were you can make a decent commission by a simple referral. Even if some of the vendors don’t have an official referral program, I’m sure that most would be happy to talk to you about making something like that work for you if you are bringing them real business that wasn’t already part of their pipeline.

Training & Support: Become real experts of the solutions that you are proposing and go to the extent to offer training & support. Even if the SaaS vendors offer support and training on their own, you have the upper hand of up-selling your existing customers who already trust you as their loyal advisor plus it will make you that much better selling the solution since you know it so well.

Integrations: Native SaaS applications are inherently built to scale (the ones that are properly architected at least and if yours isn’t, check out SaaSGrid for some help!), this requires the applications to be built as service oriented applications so by default most properly written SaaS applications will automatically expose APIs for extensibility and integrations via web services. If you are a technical enough shop, you can actually provide value added services by extending the SaaS application or bridging two solutions much easier than you would normally be able to do in an on premises application.

Consolidation: If you are offering your customers multiple services, you can actually consolidate the services for them and give them additional benefits like central billing and alike.

Clearly these are only a few ways that VARs can play a role in the space and some changes to your core business model might need to be made but what I’m interested to know is really what you think? Are you a VAR making money with SaaS? If so, what are you doing and how is it different than your other traditional on premises offerings; also, how is it affecting your bottom line? If not, why not?

Join us and share your thoughts through the comments. Also If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 2400+ members and is growing every day; make sure you’ re not missing out and join today!

read more

Can Open Source & SaaS Get Along?

Sep 26, 2007 by Sinclair Schuller

Many things in life tend to be mutually exclusive: you can’t drive a car and fly an airplane at the same time (not yet), you can’t be underwater and breathe (at least not without an apparatus) and you most certainly can’t talk and listen at the same time (believe me, I’ve been trying to perfect this for the longest time). Many will have you believe that Open Source and SaaS as a pair of business/distribution models also fall into this category. A simple Google search unearths a bevy of “Open Source vs. SaaS” information. Within the blog space, different ideas have sprung up: Ben Kepes blogged about the merger of the two and Bob Warfield followed up. Anshu Sharma even touched on the topic in this post. One thing is certain from my perspective: SaaS and Open Source are most certainly not mutually exclusive.

When looking at software business/distribution models I see a few important questions that need to be answered in order to understand the “source to market” relationship as well as the potential for exploiting different ways to generate revenue:

1. Who Built the Software?
2. Who Added Value to the Software?
3. How is the Software Distributed?
4. Who Wants the Software?

Understanding the choices for each of those questions can highlight what possible paths can be taken. Visually, these questions and potential answers can be captured as follows:

Based on this “source to market” stack, I find it very easy to treat the Open Source Community as one of the many implementation mechanisms for software, irrespective of how the software is distributed or who wants it. (UPDATE: As Jim Donovan pointed out in the comments, a worthwhile addition would be “Internal IT” to the who added value part of the stack.) I’m satisfied by the notion that how software is implemented has little bearing on how it can (and should) be distributed, hence allowing SaaS (a distribution model) and Open Source (an implementation/licensing model) to co-exist (If there is some insurmountable contention I’m missing, please do leave a comment!). An example (although not the best example) is SugarCRM: a community develops the open source core, SugarCRM adds value through more feature-rich versions, and the software gets distributed both on-premise and on-demand. If we lay a map over the previous diagram for a concept similar to SugarCRM, we arrive at this:

When building a business/distribution model, understanding the abstraction between interacting layers (or acknowledging that they exist) can be powerful. I think there is a lot of work to be done in creating a powerful “Open Source/SaaS Merged Model” (I don’t think Sugar has the best approach yet), but we should by no means use “versus” to describe their relationship. One thing we can all agree on is that many of these concepts are better than this:

Any thoughts or comments? Is a merger between the two not possible, or is it inevitable?

 

read more

Is there room for a SaaS hardware play?

Aug 1, 2007 by Sinclair Schuller

I recently had a conversation with a friend regarding SaaS and hardware VARs. The topic came up because this friend noted that hardware VARs will undoubtedly feel the SaaS pinch: if enterprises start overwhelmingly subscribing to software rather than purchasing it, they buy less server-oriented hardware. Although providers will be buying the hardware to host the SaaS offering, economies ought to consolidate the amount of hardware necessary to provide the same amount of functional utility. This chews into the total market revenue. But does this have to be a “net loss” game? Absolutely not!

 SaaS, aside from all of the business driver gobbly gook, does one thing very well: it mobilizes data and functionality since by nature SaaS lives in the cloud. Hardware VARs need to exploit that. Through creativity, endpoint hardware devices that integrate with in the cloud services can become a very lucrative market. Take a logistics SaaS offering and GPS devices, or an inventory control SaaS offering and lightweight mobile laptops with integrated scanners, for example. I think traditional VARs would do themselves a favor to spread out some and into these endpoint offerings rather than focus on the “next big server sale.” It seems that diversification will be the key. Any thoughts?

 

read more