SaaS 101: The Benefits

May 2, 2007 by Abe Sultan

In Matt’s previous post, he made mention that the true sign of SaaS’s arrival is that it has garnered the sincere interest, and better yet dollars, of the investment community.  More people in a greater array of business roles are giving SaaS the ol’ thumbs up.

We’ve established that the pursuit of SaaS is on the minds of *almost* everyone, but what is it about SaaS that gives us all the warm and fuzzies?  For the most part, SaaS is still a nascent industry.  It wasn’t long ago the purveyors of SaaS applications or enablement technologies were referred to as the tech industry’s “lunatic fringe”.  Strangely, the benefits of SaaS have emerged and shown a bright light on the future of all those involved in delivering software functionality to businesses.  So, what are these benefits? This may read like a SaaS 101 laundry list… but to see where SaaS is going, it might be best to take another look at the fundamentals.

For the Consumer:

• No client/server software installation or maintenance – that’s right, no more 800-page planning and implementation guides.
• Shorter deployment time – potentially minutes as opposed to a phased implementation that could take months (see item #1)
• Global availability – sure the technology exists to make on-premise software available outside of the premises, but we’re talking about functionality that is available from anywhere on the internet natively.
• Service Level Agreement (SLA) adherence – reported bugs can be fixed minus any rollout overhead.  Sure the provider actually has to fix the issue, but assuming they’ve deployed a moderately efficient SaaS application the rollout of a patch or fix should happen in the blink of an eye.
• Constant, Smaller, Upgrades – when you use a SaaS application, it is in the best interest of the provider to keep you happy and they can do so by constantly improving the application experience.  With SaaS this can come in the form of consistent miniscule changes that add up over time instead of monster patch and upgrades that cost you time and money to implement.
• Ease Your Internal IT Pains - This is a big one. Most of the last several points here highlight that SaaS offloads a great deal of IT pains incurred by software consumers in the traditional client/server model.  This leaves IT personnel to focus on improving the day-to-day technical operations of your company instead of being called upon to troubleshoot 3rd party software or maintain aging infrastructure.  Which leads to…
• Redistribute IT Budget – by outsourcing software functionality to a provider, the enterprise realizes a cost savings in infrastructure requirements and IT personnel knowledge requirements.  This allows the enterprise to focus on core competencies.  It also means that the cost savings from using SaaS applications can be flat out saved, or reallocated to boost productivity through other services.

For the Provider:

• Aggregate operating environment - as a provider, you own your domain.  No longer are you sending technicians to fix or customize your software because it doesn’t fit into a customer’s highly-specialized (or horribly outdated) infrastructure.  You have complete control to optimize an infrastructure to your SaaS application’s specific requirements.  This is synergy at its best, and leads to financial savings as well as less headaches.
• Predictable Revenue Stream - the subscription model associated with SaaS means that your customers will pay you on a recurring schedule.  If you make this cycle flexible enough, you can get a real handle on forecasting revenues.  The payment may be tied to your product (think cell phone plans) where everybody pays according to the same term, or tied to your individual subscribers where some may pay monthly, some yearly, and some quarterly.  In my opinion, the more flexible you are with this piece of the offering the better.  Either way, because of the scheduled nature of cash inflow, revenue modeling becomes more reliable.
• Predictable Growth - Same as above, but here we’re talking about sheer volume of subscribership.  The fact that users hit your site to access the application means that with the right tools you can monitor their usage pretty closely – something that’s not so easy with all your customers running the application on premise.
• Focus On Smaller Upgrades Instead of Monster Patch Rollouts – and while you’re at it, don’t worry about rollout logistics across all of your customer sites either.  Your development teams can focus on fixing core application functionality, tackling bugs and enhancing features in smaller incremental rollouts because it’s just easier to do so.
• Sales Becomes Customer Relationship Management – When you are selling a subscribable service, the game of gaining subscribership becomes one of balancing user retention vs. attrition more than a game of landing the ‘big deals’.  Sure, it’s important to have a team out there pounding the pavement to sell your application – i.e. getting subscribers in the door - but the real thrust of the new sales and marketing in SaaS is customer relationship management.  The equation becomes quite simple – keep retention rates higher than attrition rates and focus on bringing in new customers.

Adoption of the model has been growing at well over 20% year over year, Nick Carr says (paraphrased) that SaaS adoption is set to explode and reports that McKinsey & Co. will release a survey showing that 61 percent of CIOs at North American companies with sales over $1 billion are already planning to adopt one or more SaaS application.  Additionally he says that Deutsche Bank projected that the SaaS market will account for half of the application software spend by 2013, Gartner predicts that SaaS will triple in size by 2011 from 2006, Jeff Kaplan thinks SaaS adoption is underrated and the success of companies like SalesForce.com should be enough to convince even the most skeptical, but if all of this is still not enough and you are having trouble convincing your customers, your boss or yourself into adopting SaaS, here is a list of benefits to consider.

What do you think? Have you experienced other benefits already? On the contrary, have you experienced major drawbacks? We would love to know what’s holding you back or what has pushed you forward!

read more

Build vs. Buy and Economies of Scale

Apr 19, 2007 by Matt Ammerman

When formulating the architectural foundation for a SaaS application, ISVs will inevitably encounter the age old build vs. buy decision.  SaaS enablement is hot right now, giving vendors a plethora of options on the buy side. 

Nick Carr has an interesting argument in support of the buy scenario – specifically urging vendors to buy into a horizontally aligned platform serving multiple vendor-instigated verticals because issues arising with subscriber usage and economies of scale.  The example Nick gives is Intuit’s TurboTax online, explaining how the service from this system ground to a snail’s pace because of the mad rush of Americans filing taxes earlier this week. 

A similar example would be the usage peaks that a CRM application will experience at the end of each quarter as sales are tied up at a frenzied pace.

As an ISV, if you need to provide high availability service but that service is prone to suffer unusual high peak times, having ‘anticipatory’ hardware lying in wait can be quite cost prohibitive.  So what’s the solution?  As in most cases, aggregation of resources leads to economies of scale.  Platforms provide that aggregation, normalizing the usage spikes across many vertically-aligned vendor applications.  As Nick puts it, the only way to do this is by sharing the resources with other companies that also need high availability service but whose peak times are different than yours.  It is simply a matter of economies of scale, and platforms are able to achieve these economies through mass aggregation of requirements and management of resources.

Platforms like Apex and SaaSGrid aggregate infrastructure requirements, and taking the solution a step further by providing guarantees of service at any point in time without ISVs explicitly having to build out an infrastructure or request a larger slice of the computing pie during high volume times (unlike an MSP scenario).

read more