Category Archives: SaaS

This Week on The Web 2009-09-13 (my birthday edition)

It happens to be my birthday weekend and between eating some great food, playing Guitar Hero with my wife and hanging with the family, these are the things that happened around the web this week – maybe you already read about them, maybe you need to again – there were some REALLY great discussions going on.  Come join the party on twitter (follow me here and you’ll join the conversation live.)

I also realized that many of you might have no idea what you’re seeing below.  Sorry.  These are “tweets”, 140 maximum character messages sent via Twitter.  Within the Twitterverse individual users follow others and have followers (think of it like overlapping Venn diagram circles).  To read a tweet, you have to wade through a bit of jargon used to make the most of the 140 character limitation.  “RT” for example, is shorthand for “Re-tweet” and the @____ is the username of some other individual on Twitter.  Combined together, then, “RT @_____” means that someone else wrote a tweet that I found important and I now want to forward along to my followers.  The URL’s are then also shortened by shortening services like bit.ly to make the most of the character limitation, too.  Lastly, you might see “hash” identifiers “#______” which are ways to tag tweets of a particular flavor for easy searching later and “<” which means that I am commenting on what came before it.

This Week on The Web 2009-09-06

The things that happened around the web this week – maybe you already read about them, maybe you need to again.

I also realized that many of you might have no idea what you’re seeing below.  Sorry.  These are “tweets”, 140 maximum character messages sent via Twitter.  Within the Twitterverse individual users follow others and have followers (think of it like overlapping Venn diagram circles).  To read a tweet, you have to wade through a bit of jargon used to make the most of the 140 character limitation.  “RT” for example, is shorthand for “Re-tweet” and the @____ is the username of some other individual on Twitter.  Combined together, then, “RT @_____” means that someone else wrote a tweet that I found important and I now want to forward along to my followers.  The URL’s are then also shortened by shortening services like bit.ly to make the most of the character limitation, too.  Lastly, you might see “hash” identifiers “#______” which are ways to tag tweets of a particular flavor for easy searching later and “<” which means that I am commenting on what came before it.

This Week on The Web 2009-08-16

The things that happened around the web this week – maybe you already read about them, maybe you need to again:

Four Disadvantages to Using SaaS for Your Small Business

This is a blog response to DreamSimplicity’s “4 Advantages to Using SaaS for Your Small Business“.  DS is correct, SaaS offers several great advantages that small businesses can exploit – such as obtaining access to enterprise-class software once priced outside non-enterprise reach.  But all is not rosy and wonderful in the SaaS world.  It pays to consider all options before moving ahead with any software product, and some risks are exacerbated by a SaaS environment.  Here are four to consider:

  1. You’re still small and probably have no leverage to negotiate the license.  Even SaaS vendors offer negotiable software licenses to customers who buy above a certain threshold.  As a small business, you’ll be less likely to meet that threshold and will be tied to their unmodified EULA.  Take the time to read this document carefully, it’s the setup for the next three issues.  Oh, and just because you’re small doesn’t mean you can’t TRY to negotiate.  ALWAYS ask for the changes you want – the worst they say is “no.”
  2. The SaaS provider is going to have your data.  Building your business from the ground up within one of these platforms is terrific.  However, once you mature to the point where you consider switching, you might only now start to consider how to get your data out of the system.  If you think of this up front, you might be able to get a small change to your contract to allow you easy access to your information.  If not, do the research to see how you can export data.  Zoho, for example, is awesome.  But there’s almost no way to easily get all of the data from a fully-populated database out of ZohoCRM.
  3. The SaaS provider is going to be storing your data.  Depending on your business, you might have certain regulations governing the acquisition, storage and use of the information you gather from customers.  Again, if you’ve clicked “I Agree” to the standard EULA, chances are, the vendor isn’t offering any real protection of data.
  4. You have to consider the potential for your provider to go out of business.  With the SaaS model, you only have access to the application for so long as the provider is viable.  If the provider goes away tomorrow, so does your access to the application (not to mention your data).  As a small business, you probably won’t have access to some of the enterprise-class contract provisions here either – such as escrow, guarantees for unexpected terminations… heck, even termination notice.

So, while SaaS can offer extremely valuable opportunities, there are pitfalls, too.  Just be aware – for even if you can’t do anything about these issues from a contractual perspective, you can try to deal with it from a business planning perspective.

Interesting Tidbits

I’ve not done this before, but given that I just got off vacation and have an inbox that would scare most people, I thought a few tidbits of things passing my desk might be of interest to you:

The Ideological History of the Supreme Court of the United States

A White Paper on Insurance Coverage for Cyber Security Losses (e-mail required)

The Applicator on “Chiseling on Demand”

Thirty Interview Questions You Can’t Ask and Thirty Sneaky, Legal Alternatives to Get the Same Info (hat tip to D.C. Toedt)

Salesforce.com calls for End of Maintenance

Below is the contents of an internal salesforce.com memo CEO Marc Benioff shared with Vinnie Mirchandani (and posted on his blog: deal architect).  I’m pasting it here for simplicity’s sake and because of the power of the message itself.

“For ten years, we’ve been driven by a simple vision: The End of Software.  Now it’s time to take on a new challenge: The End of Maintenance.

Let me tell you about a customer that I met on our Cloudforce tour. This customer currently uses Siebel software to run her call center.  She pays more than $15 million a year for the privilege of having to implement the updates that Siebel sends her.  That does not include backup. Or disaster recovery. And of course, it does not guarantee that she will be using the latest technology.  The maintenance agreement only assures her that her outdated software will continue to work.  She is paying tolls on a road to nowhere.

We can help her, and many other customers, and deliver much more for a fraction of what they currently pay in maintenance. It’s time to open up a new front in “The End of Software”– one that is long overdue.

It’s time for The End of Maintenance.

Every year, companies spend billions on maintenance fees and get relatively little in return. Maintenance fees cover updates that are mostly  patches and fixes, but they stop far short of the kind of innovation every that enterprise needs to survive.  Companies pay to keep the past working and they end up doubling down on technology that can never keep up with their needs.  The fees that companies pay have actually been rising, from something like 17% a few years ago to numbers more like 22% today. Every four or five years, companies are paying for their software all over again.

It’s time to set these businesses free and make them successful in the Sales Cloud,  Service Cloud and on our Force.com platform.

Our new mission begins at a critical time in the economy, when companies are questioning conventional wisdom as they never have before.  That, of course, extends to their IT budgets as well. The CIO is in a tough spot right now.  Corporate budgets are tightening.  And our rivals in the legacy client-server world are using this opportunities to extract more money from their customers by raising maintenance fees.  I call this phenomenon “the compression of IT” and it resonates with just about every CIO I speak with these days.

We have a better vision. We sell our customers a service and every customer is able to use the latest. Innovations are included. Upgrades are automatic and invisible. Customers’ intellectual property of customizations and extensions is rigorously preserved, and carried forward without disruption.

The service gets better, not just less buggy. That’s not what people are getting for all those fees that supposedly buy them “maintenance.”

It’s time to set these business people free: to give them the experience of being wildly successful in the Sales Cloud, the Service Cloud, and in their own unique applications that they can build on our Force.com platform. This is the time to do it, because this is when people need it: their IT budgets are tight, their business situations are critical, and their old-world software vendors are taking care of themselves instead of meeting the needs of their customers.

We’ve raised people’s expectations for better alignment of business value with IT cost. We’ve earned our leadership position in enterprise cloud computing. It’s time for us to set people free from paying more and more to get less and less. It’s time for The End of Maintenance.

Aloha,

Marc”

More on 5-9 Availability

I had a few posts on 5-9 availability in the last two years.  Today, ZDNet reports that 3Tera is offering 5 9’s.  The really positive thing I saw in the article is that 3Tera plans to provide automatic SLA credits in the event of downtime that blows the metric – which, if there’s truly 5-9 availability, shouldn’t take much doing.

I’ll ask the question again that I asked before:  Is it worth the cost?

Notes from the “I told you so” file

Well, it didn’t take too long.  C-Net reports today that Google inadvertently shared some Google docs files with folks they weren’t supposed to be shared with.

Lifehacker ponders whether this is a “minor privacy blunder”.

Meanwhile, Google is busy blaming it on the user (italics are mine):  “We’ve identified and fixed a bug which may have caused you to share some of your documents without your knowledge.”

Yeah, Lifehacker, this isn’t minor.  It never is.  Especially to those individuals who have data that was shared without knowledge.  Oh, and C-Net, you shouldn’t downplay this either – so while mentioning that lost laptops are a security risk, too, it doesn’t do anything to resolve the issue at hand.

Look folks, any breach of privacy, especially in a SaaS/cloud-computing environment is a HUGE problem.  Shore up your contracts today, please (confidentiality, IP indemnification, and exclusions for breach of confidentiality in your limitation of liability language).  Need help doing it?  Just give me a shout.

Software Licensing Education Series – 400s Track Now Available!

Designed for the busy or on-the-go professional, the Software Licensing Education Series (SLES) is video-based training on the complete gamut of software licensing topics. Presented in a college-course level format, with topics increasing in complexity and building upon prior lessons, the SLES allows an audio-visual learner another way to gain knowledge on licensing topics.  Each video is approximately 20-30 minutes in length, so each Track contains about 2 hours of expert instruction in core software licensing topics!

The 400 Track videos include:
SLES 401 – Services Issues 2
SLES 402 – Maintenance and Support 1
SLES 403 – Maintenance and Support 2 (special 1-hour course)
SLES 404 – ASP and SaaS Issues

(500s Tracks are currently in production and will be released shortly!)

Videos are formatted for a computer or portable video player (such as an iPod) and consist of a slide-show format with voice-over instruction, so you can even learn just by listening!

99.999

Back in the day, we used to fight for five-nine availability.  This meant that you would have access to the product or service 99.999% of the time.  (If you’ve not read Wikipedia’s article on the Myth of the Nines, now’s your chance.)  Mathematically, this equates to only having 5.26 minutes of downtime a year.  Pretty impressive, when you consider how long it takes the average computer to simply reboot.

We would tie the availability requirement to a penalty (aka “financial incentive”).  This is a kissing cousin to service and support response/repair times and similar penalties… and it heavily applies to situations where you need steady and consistent access to a particular product.

For ASP/SaaS products, uptime is extremely important, as it not only defines the amount of time you have access to use the product but also is a measure of the service provider’s value/responsibility (you don’t have access to the product to fix it yourself).  Until recently, though, network bandwidth wasn’t really available to sustain the offerings and was the scapegoat for much of the argument to reduce or eliminate uptime requirements, even if it was the vendor’s back-end server performance causing the problem(s).

As a result, compromises were made to allow uptime calculations only based on daytime work hours (so downtime at night wouldn’t be counted) for those businesses which didn’t have 24/7 operations.  Compromises were also made to allow vendors the ability to challenge a request for credits based on downtime.  Of course, compromises are fine so long as you’re not compromising your business model.

Flash-forward almost a decade.  Gigoam commented recently about the fact that the current movement towards more cloud-based computing is going to require more attention towards availability.  I agree.  And I’m a little disappointed that I haven’t yet seen a likewise return of significant uptime commitments.

The bandwidth is here (to understand the difference between then and now, check out this table and compare 10Base-T versus Gigabit Ethernet, almost a 1000x speed difference) and applications are designed to be a little more efficient, too.  The result is a resurgence of ASP/SaaS products.  There are several that I love, actually.  They’re incredibly good products, with good support and they don’t typically have downtime problems.  But I’m not seeing uptime guarantees of any significant amount.

To get decent uptime availability commitments from your providers, you need to be in-the-know regarding your own proposed usage and the product offering:  Know what the service’s value is to your organization.  Know when it must be available and when it can be down.  Know about server-loads and peak-usage periods.  Know the difference between hot/warm/cold backups and have an understanding of what failover might require.

99.999% availability might never be offered again… but something should be.  Make sure you’re asking for an uptime guaranty from your providers. Never forget that the middle name of ASP and the last name of SaaS is service.