A retrospective from someone familiar with the SaaS ISV trenches

Mar 24, 2008 by Matt Ammerman

This post simply serves to provide a link to a post on another site, but I felt it very appropriate to shine the spotlight on a brilliant post by Ben Yoskovitz on Instigatorblog.com entitled ‘Lessons Learned Running A SaaS Business‘. While we tend to focus on the relative “newness” of SaaS, it’s always important to remember that there are people who have been approaching, solving, re-approaching, and re-solving the challenges associated with SaaS for some time now. Ben outlines some key points from a “looking back” perspective. Give it a good read, there are tons of gems throughout – especially for those building go-to-market strategies for SaaS products.

read more

SaaS & Learning from Malcolm McLean

Mar 17, 2008 by Sinclair Schuller

For those who don’t know who Malcolm McLean is, I’ll give a brief introduction. Malcolm McLean invented the modern shipping container: you know, the ones that come in on cargo ships, are craned onto trucks and trains, and that provide a standard for transporting goods worldwide. So why are his ideas important and what does it have to do with SaaS? I think we should all pay attention to the shipping industry and how he revolutionized it. SaaS and service oriented architectures have the potential to cause a change as profound as the one experienced by the transportation world in the 1950s.

Traditionally, software is notorious for capturing functionality and locking it away in an unsharable fashion. Any other piece of software interested in tapping into some other software’s functionality generally needed access to the source code or some non-standard programmer interface. This isn’t necessarily the fault of any one piece of software, but rather a problem of lack of basic agreement. Software lacked (and still somewhat lacks) protocols, well-defined modular architectures, and an economic model allowing for subscribed functionality that can compensate producers in a producer/consumer model.

In the shipping industry, McLean recognized some significant parallels: across transport mechanisms (trucks, trains, and ships) there was no efficient protocol (everything was break bulk) and economic models in transportation reflected a heavy penalty because of lack of disintermediation (someone had to interfere at each drop point to break down shipments). By introducing shipping containers and associated support infrastructure (crane structures, roll-offs) etc., we saw those issues alleviated. McLean broke the mold by recognizing that lack of standard produced inefficiency and not competitive advantage.  This is why these days you’ll see the same shipping container on the deck of a cargo ship, on the bed of a freight train, or on the back of a trailer heading down the interstate.

In the software space, we’re starting to recognize that lack of protocol, economic models, and isolated functionality are in fact hurting us. Service oriented architectures have shown that cross-technology communication and access to non-commodity functionality is possible from a technical standpoint, that applications can in fact be very modular (just look at the mashup craze), and that software as a service has introduced an early framework for monetizing this functionality between parties. Looking back at McLean and what the shipping industry is today, we should recognize that his work and ideas led to the ability to transport goods across the globe as efficiently as possible and that we have a similar duty in the software space.

Over time, do you expect that software space to become more protocol driven and more flexible in terms of functional composition, or have we reached our peak with respect to “functionality on tap”?

 

read more

SaaS as Recurring Revenue Justification

Nov 20, 2007 by Sinclair Schuller

One common misunderstanding (at least in my opinion) I find when discussing SaaS with people (particularly SaaS vendors) is that they make statements like “SaaS is nice for business because it’s recurring revenue.” Why is this a misunderstanding? Well, the way that statement is framed is that SaaS gives the SaaS provider the benefit of recurring revenue. Instead, the topic of recurring revenue and SaaS should be framed under recurring payment from the consumer in exchange for recurring, high quality delivery of software functionality. It makes the issue seem much less one-sided and is a more accurate representation of what happens (Yes, I have a penchant for definition nuances)

A recurring revenue model, however, is exactly that: a revenue model. Conceivably, I can sell someone on-premise software and ask to be paid $500 a month for the use of the software as long as it is being actively used. Conversely, I could have a SaaS offering and sell it on the basis of “Give me $50,000 and up to 6 users can use it forever.”  There is no direct coupling between the delivery model and the revenue model and with some craftiness I could use any combination of delivery and revenue model. In essence, I can achieve the benefits of stable, long term, and predictable recurring revenue or the benefit of large revenue influx and good periodic cash position via perpetual license sales without worrying myself about how software is delivered. Technically, we have the following four combinations:

1. On-Premise, Perpetual License
2. On-Premise, Recurring License
3. As a Service, “Lifetime License” (a re-labeling of perpetual to fit the SaaS conceptual framework)
4. As a Service, Recurring License

So what then, is so special about the coupling between the SaaS delivery model and the recurring revenue model? From the provider perspective, it makes the recurring revenue model an easy sell since its justified. It’s tough (although possible and has been done before) to sell an on-premise license on a recurring basis without any sort of continued, measurable participation from the ISV. The real importance of coupling SaaS with recurring revenue is actually from the consumption side of the equation. Those who use SaaS offerings get to pay as service is delivered, with the ability to discontinue use and mitigate losses when service becomes subpar or the offering no longer provides adequate return. Moreover, it also keeps providers honest and overtime keeps service quality levels high. This is a huge selling point that is not stressed enough and is significant in the SMB space since the cost associated with migrating to a new substitute SaaS offering is relatively minimal in nature and low in risk. When prospective or current SaaS providers discuss SaaS, stress should be put on the fact that “SaaS gives my customer the ability to pay as they receive service and have quality guarantees in place” rather than “I get recurring revenue” Customers don’t care if you get recurring revenue, but do care about the rest.

Do you think that SaaS is necessary justification for recurring revenue, or could recurring revene models be justified using “old” on-premise delivery/other delivery models? How important do you think “pay as service is delivered” is to SaaS customers?

 

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