In this episode, Robert and I talk about Software as a Service, or “Saas” as it is often called. This software delivery method gets a lot of attention lately, but is this really anything new?

Saas today could be called an evolution from the old days of Application Service Providers, or ASPs. In the ASP model, companies rent out IT infrastructure, both hardware and enterprise software. The biggest benefits of ASP seen by most companies is usually the ability to expense the infrastructure and hosting – they’re not buying a bunch of hardware and network pipes, paying for the maintenance, etc – and getting stuff that’s probably not a core competency (like all the resources needed to maintain that hardware) off the books.

But I think it could also be said that Saas grew up out of simpler forms – the early web forms, cgi scripts and databases that appeared in the earliest days of the web. As a web developer in that period, I was building these kinds of very simple things – we didn’t think about them as “applications” or “software” at the time - that were automating basic processes.  But really, it was the same basic components. HTML presentation, server side processing and a database to store and retrieve information.

So instead of taking an on premise application and putting it on a remote server, we’re talking about building application-level functionality into a web site. Along the way, we’re evolving it up and taking advantage of the advances in web technologies (java, css, javascript, ajax, etc).  The real differentiator is that first S – the Software, not really model of delivery.

The common theme is offloading your hardware and infrastructure costs. An ASP will maintain the equipment, the network pipes, really everything that makes the software run. Beyond that, the ASPs would offer varying levels of service (for a price) that might include implementation or upgrades.

Whereas with CRM On Demand, we’re delivering a multi-tenant application – and we’re providing it as a subscription. It’s built from the ground up to be web delivered – not something a lot of enterprise apps would claim.

And that may not seem very significant, but it is. Now we’re talking about sharing resources, sharing a database, sharing the overall codebase.

What are the top things a company should know before going Saas?

The vendor relationship is far more important than with packaged aps. You can buy software off the shelf or from a reseller or from the maker and you end up with a bunch of CDs in a box, a stack of manuals, etc. The vendor has done their job. Not so with Saas. Viewing the vendor as your partner and learning to work effectively with them is key.

To give you an idea of why you need to take this new vendor relationship very, very seriously, these are a few of the items that are no longer under your control

1. The vendor determines when the application goes down for maintenance.

 All corporate IT systems have maintenance periods, but when your system is a multi-tenant environment running critical applications for hundreds or thousands of customers, the saas provider is going to institute a standard plan – usually in the form of an SLA. Got a last minute need for the system on Saturday morning? Don’t count on getting the vendor to change the window.

2.  The vendor drives the technology upgrade curve

Feel your CRM application is missing a critical feature? It’s up to the vendor to decide when and if that feature is important and when or if it will be deployed. Not that your voice isn’t heard – it’s just got a lot of company!

3. What is the response time to outages?

Be familiar with the vendor’s commitment to recovery times when something goes wrong. Generally there should be some up-time guarantee, but again, if we’re taling about a fairly minor component failure, you are trusting the vendor to share your priorities.

So, the question is, do you trust the new vendor with all of these responsibilities? Keep in mind that your needs and desires will be balanced against hundreds of other companies.

The good news is that CRM On Demand and other Saas offerings are managed extremely well. Probably a lot better than most companies could do internally. And while you may have to wait for that specialized feature, I can tell you that they do listen and weigh customer requests.

The overall message here is that you need to look at the vendor as a partner. Partner. They aren’t going away, so think about the relationship you are forming and do your homework to ensure you know how best to work with them for the next, oh, forever.

Saas applications are different.

In the current saas environment, applications are built differently than packaged apps. They have to be to realize the efficiencies that make the model profitable. They are engineered to be faster to implement, to have applicability to a broad market. In the case of CRM On Demand, it is built around CRM best practices – pre-determined business processes supported by a core entity model. Understand what is there and use it effectively.

 Hosted infrastructure means you don’t lose sleep worrying about a hard drive failure. But it also means there are going to be both soft and hard limits on data volumes and transactional bandwidth. And if you start to approach these limits, there are limited options for testing.

For example, you may only be allowed, under contract, to load so much overall data. Further, the bandwidth you consume may be capped. The former can usually be negotiated, but the later may run into hard limits on the number of simultaneous transactions, particularly in areas like web services. Limits are put in place to protect all the tenants, so know what they are and plan for them in your development.

IT and Saas

You’ve outsourced almost everything IT does, hardware maintenance, software development, etc.? So send ‘em all home, right?

How about access to legacy data? How about data governance and program management expertise? You can’t leave IT completely out of the picture here.

We have some customers that approached CRM On Demand without any involvement from IT. The application lends itself to putting the business needs first – the technology is abstracted – and this is generally a good thing. But when it’s done outside of the broader IT strategy, then you start to see conflict.

IT possesses the knowledge and skills to ensure that whatever the business is doing will conform to corporate standards and play nice down the road when it’s time to plug them all into one happy family. Mixing metaphors a bit.

Suffice it to say that IT should indeed be evaluating their role in a Saas world – ’cause it’s not going away. But neither should they be heading for the door. It’s more important that ever to have the skills to realize a business applications strategy in a heterogeneous environment.

Saas and Implementation

It’s not only built differently, you need to change your thinking on how it’s implemented. More interaction with business owners than IT means you need to learn how to talk to them. This seems trivial, but it’s important to understand that the business folks aren’t going to speak techno jargon, so how do you translate their needs into a configuration?

Speaking of configuration – you really need to know the hard and soft limitations of the application before you finalize requirements. It’s too easy for a business owner to dream up a requirement that will cripple the system or be impossible to configure or cost a lot more in web service development costs. That discussion needs to be had before configuration even starts.

Data governance becomes really central – what data do we need? How much? How often will it be refreshed? In SaaS this is a finite equation and you have to balance resources accordingly.

Iterative Configuration – The great thing about SaaS is that you can build a screen and show it to people very quickly. Take advantage of that. Release the application in small but rapid steps.

And speaking of iterative configuration – that puts a different emphasis on post launch support. Continuous improvement implies a much more hands-on approach for the entire lifecycle of the application. You can’t just launch it and throw it over the wall to the users.

Testing and Validation is different – You don’t have the same tools, so you need to be very aware of where testing may be needed and how it’s going to be executed.

Saas Economics

Is this a good model financially for the customer? Generally, the answer is yes. CRM On Demand, like most other saas apps, has far lower upfront costs than comparable packaged software. The subscription model, in theory, allows you to pay as you go and allow you to walk away anytime. In reality almost all vendors, Oracle included, deal in annual contracts, where you’re paying for x users for the first n years up front. And while you can certainly choose to end, or not renew, a contract, you can still anticipate switching costs (getting your data, swapping integrations and re-configuring a replacement.)

Economically it typically works out that saas is a better deal for the first few years. Some studies put it at 2-3, some as many as 5 years out. After that, it could be argued that you are paying more than would have for packaged apps. But that gets fuzzy since it may not capture the true cost of upgrades – remember, Oracle does all the upgrading for you.

Also, these costs are expenses, not capital investments. So the accounting treatment alone may be more desirable to some companies that don’t want to treat a software application as an asset that has to be depreciated over time.

Is it good for the vendors? Oracle and others wouldn’t be in it if it wasn’t profitable, but the model relies on efficient delivery of the service and a stable, growing subscriber base.

There’s a lot of fixed cost there. As a vendor you’ve got to have all the machines, pipes and staff in place before even one customer goes live. So that first customer is sure to be a loss! Vendors have a huge incentive, therefore, to run an efficient operation, continually grow your subscriber base and keep customers on the system for a long time, The general rule is that a customer isn’t profitable until they’ve been on the system for 2-3 years.

Who should get Saas-y?

Sorry, that was really bad.

A happy and successful Saas customer is one that understands what they have, what the limits are, actively partners with the vendor, and embraces the iterative approach of deployment we mentioned earlier.

The one thing we can say is that every organization, from smallest to largest, is a candidate. Every IT, CIO, CTO needs to ask if the next application they are looking to implement or upgrade could be a Saas solution.

Not all will be – for strategic or technical reasons – but Saas has to be at the table.

Episode Wrap-up

It’s really been an amazing journey. I started working at UpShot in 2002 – before the term Saas was in popular use. At that time the market was really in SMB and the objections were all about security and integration. The applications were simplistic with just a handful of core functions.

Now we’ve got companies like GE and Fidelity using Saas solutions. Objections over security have largely been overcome with the entrance big players like Oracle into the market.

And integration isn’t the barrier it used to be, especially as we see more implementers entering the space and offerings like Cast Iron making it a bit easier.

Saas still has a lot of room to run – from the back office to vertical apps, to full support for cloud integration. I firmly believe we’re still in the infant – well, maybe toddler- stage of Saas. Can’t wait to see what it looks like as an adolescent.

Share and Enjoy:
  • Digg
  • LinkedIn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • Twitter
  • StumbleUpon
  • Technorati
  1. [...] and I had a lengthy discussion in our October, 2009 podcast “SaaS Talk“. We touched on a lot of the same content and reached a lot of the same conclusions. [...]