The agility of SaaS vs. the risk of On Premise

I read an article today from PC World titled SAP uninterested in enterprise SaaS

This is a very typical response from a traditional enterprise software vendor who underestimates the pervasiveness and stickability (I like that word a lot better than traction) of SaaS. Lets look at a couple of quotes from this article.

The ERP giant was "not so interested in 'drop-in' services for three or four users, he said. "We want to run the company, we want to run the business, we don't want to just support some services for some users in the company."

This simply indicates the inflexibility and non agile nature of On Premise vendors. Of course they don't want to support 3 or 4 user systems. The cost of sales and support is just too high for them. On premise vendors struggle with both providing customers with new features regularly and version control which Bob at Smoothspan blogs so effectively about.

Back in my On Premise Days we struggled with these exact same problems which haven't changed today.. We had a major product release once a year, the problem was and is how did you deploy that release to all your customers. In the end you don't.

The whole on premise product release process is non agile in nature because of the risks involved. You can't bring out a product release more than once a year because you have to test every permutation of what could go wrong with each customer's installation and build upgrade procedures for all previous versions in existence. You then announce to the customer that there is a new release with a whole bunch of new features and it will cost them 1 million in services to upgrade. They look at the new release, and then say "thanks but no thanks". They look at the risk of something going wrong in the upgrade and say its too risky and too expensive.

In the end you find yourself using your latest release for new customers only and you are stuck with a version quagmire. Its a vicious cycle as each new release then has to cope with yet another older version upgrade.


John Rowell from Opsource also posts about this issue of SaaS vs. on Premise

The beauty of SaaS is obvious, one instance of the application to upgrade and all customers benefit from new features. Because of this, SaaS becomes very agile. You can bring out cool new features once a month because you don't have the baggage of versioning and handling different customer environments.

SaaS also is a whole different philosophy when you begin looking at user counts.
SaaS doesn't care if you are 25000 users or 3 to 4 users. It can handle it all. There is no "sorry you are too small for us". SaaS can't handle large user count systems? Somebody better tell Salesforce.com that, earlier this year they closed a 25000 user deal.

"They would prefer a quick win, that could be some CRM functions on demand," he said.
They might later want to bring in on-premises software, he said. "That would take the risk and cost down."

It was suggested in this article that SaaS was seen by enterprise customers as a short term fix before going to a long term on premise solution.

Once again I will speak from personal experience. We had one enterprise prospect, it was down to us and a traditional on premise vendor, we won the deal because our competitor quoted an 18 month project, with a 7 figure cost, plus annual maintenance fees. We offered a SaaS solution and said we could roll out immediately and would release new features once a month. 6 months later we had one thousand users in multiple countries all using the same instance as all other customers. Consolidation of country data was painless, (can you imagine what this would have been like with an on premise system) and customer feature requests were being delivered monthly with our entire client base benefiting from these enhancements.

Can you imagine a customer in this scenario saying lets implement this SaaS system just for the short term and then go On Premise in the long term? Not Likely...

Scrum in a FDA regulated environment

I was asked the other day about how you could possibly implement a Scrum development methodology in a regulated environment. In the past I dealt with many CRM systems which had to comply with PDMA and 21 CFR Part 11 compliance for systems involved in the physician sampling of controlled substances and RX drugs in the US market.

This post isn't strictly about SaaS but I still thought it worth blogging about.

When building software within FDA boundaries there are certain key processes which need to be adhered to, to ensure your software is 'validated' and to reduce the chance of irregularities being discovered by FDA or Customer Audits before you find them yourself.

The key starting point for this conformance is a Quality System. When Auditors come in, this is the first document they ask for, "Where is your Quality Manual?". They will then perform an audit to verify that your product release processes conform to what you have written in your Quality System.

Now the traditional process in this case has been the Waterfall method, with a top heavy design document stage. This process really means big lags between releases and continual revision of documents and the required re-validation of documents and coding after change. The revisions were unavoidable in waterfall as no one got to review the product until close to the end of the long development phase. Then there is the good old Traceability Matrix. This is used to ensure that every requirement bullet point in your 180 page document Functional Spec and 200 page Design Document is traceable through all stages of the Waterfall. An impossible task to get right the first time. We are talking potentially thousands traceable points. When undergoing validation, random checks through this matrix would undoubtably find a missing link and things would have to start over again.


This is in contrast to Scrum, with its iterative release process, sprint cycle of 3 to 4 weeks, daily meetings, managable small sets and clear cut requirements and early feedback. The traceability matrix is small and easily tracked and issues are found early on as the progress is visible on a daily basis.

The perception has been you cannot use SCRUM in this regulated software environment. But in reality, what auditors are looking for is a Quality System you have implemented which is consistently being followed to ensure compliance with the legal aspects of your software. So if your Quality System states that you use Scrum Methodology and that your documents contain the expected FDA Requirements, as long as you are conforming to your quality system during your development projects, then you will pass validation.

Why SaaS will become the preferred solution over On Premise.

I just answered a linkedin question about what will become the predominant solution SaaS or On Premise. I thought it worth posting about.

Firstly lets have a look at why some organizations may have a natural resistance towards SaaS. An Article in CIO magazine lists a number of these reasons which I summarize here.

1. Service levels cannot be guaranteed by SaaS vendor
2. Lack of configurability
3. Sharing functionality with hundreds of potential competitors
4. Elimination of CIO role

I will add a couple more here

1. Hosting data outside of firewall.
2. Loss of control due to business units running "rogue" IT projects using SaaS.

Lets take a look at why these 'inhibitors' become non-issues for SaaS.

1. Firstly SaaS Service levels. Gone are the days where a startup SaaS vendor will try to host their own service. This is not a core competency, as such SaaS vendors follow their own value proposition ie find an expert to handle Hosting and service levels. Companies such as Rackspace and Opsource will handle this side of the business with guaranteed up times.
2. Lack of configurability. SaaS obviously enables you to implement a system which can be used in a very short amount of time, bypassing on premise challenges such as server provisioning and software installation. However SaaS does not mean the end of configuration. Salesforce.com as an example provides a very flexibility platform for building your own custom objects and UI, as do many other vendors. This enables you to model the 20% of your business process which is unique to you.
3. Sharing functionality with other organizations. This works both ways, sure you may have had an idea which the SaaS vendor has taken and made available to others. But this means you too will benefit from other organization's ideas. Furthermore the uniqueness of your business process is part of the configuration model mentioned in item 2 above, it is not part of the standard functionality of the multi-tenant single instance.
4. The CIO role will not be eliminated. In fact I see it going the other way, where it becomes even more a strategic organizational role. The CIO must make decisions on what is SaaS and what is on premise, they also need to determine how these systems integrate and how information is conveyed within the organization.
5. Data outside of the firewall. This continues to be a major topic in the news. But as the trend of utilizing data center experts such as Opsource and Rackspace increases then the risk continues to reduce, as these companies' entire success hinges on security and reliability.
6. Rogue Projects. Many time business units within an organization will look to a SaaS solution as they have been told by IT that their needs cannot be serviced in a timely manner internally. As SaaS becomes more widely accepted and recognized by Internal IT not as a threat but as an asset then SaaS projects will not be seen as rogue projects but rather an IT recommended solution. This will enable CIOs to adopt SaaS in a more structured and integrated approach.

The current generation of CIOs may have these inhibitions towards SaaS and will take time for these 'fears' to be overcome.

However what ensures the longevity of SaaS is the next group of CIO's who are in college or have recently joined the workforce. This crop will see Web 2.0 as a totally natural way of doing business as its what they do in their personal lives.
Storing files and documents, in Google, in Microsoft Live, social networking, wikis all are ingrained in this new generation and SaaS will become the obvious choice.

Is SaaS a profitable business model?

Read a blog post today by Charles Fitzgerald.

I'm simplifying a little here but Charles basically discusses the challenge of profitability when there are high costs of acquisition and of retention which then extends the time required to recoup the costs from the subscription revenue. Salesforce.com and NetSuite are used as case studies, along with examples of the cost of sales cycles and their balance sheet numbers.

The temptation in this scenario is therefore to focus on enterprise sales, the higher user counts would then offset the cost of sales. Now this makes sound business sense looking at pure financials.

The problem I have with a purely Enterprise strategy is that it leaves the SMB market underserved. This got me thinking.

Back when I was involved in selling and implementing on premise or ASP hosted Life Science CRM we had the sample problem, the cost of selling and in fact the cost of implementation were the same whether it was a 30 user site or a 2000 user site so we much preferred working on the larger sales opportunities, so its something that isn't new and unique to SaaS. In fact in those days we didn't get full payment until implementation was complete, accepted and rolled out, so it could take months to recoup the cost anyway.

However lets take a look at the breakeven equation, as per above you could go for the larger user counts (Enterprise) to offset the acquisition costs OR you could look at making the cost of sales so low that its inconsequential.
(you could also try upping your subscription prices but that would make you vulnerable to Competitor pricing)

The question then becomes ...
Why would you attempt to sell to SMB's the same way you would as Enterprise? .

Firstly, what is the cost of sale comprised of:
1. Sales Rep Time and Remuneration
3. Salaries of Operations people involved in the sale
4. Travel?
5. Opportunity Costs

The greater the time a sales rep spends on one sale means less time available for other deals, which means you are forced to increase the size of your sales force to handle leads. If your product is overly complicated then you need a larger team of presales engineers for demo purposes.

It seems to me then its really the people involved which incurs the cost.
Rep face time in the Enterprise world is about relationship building,
A successful SaaS selling model is different. Remember, SaaS is a state of mind.
You're evangelizing a way of purchasing and using software as much as a product.
Which means a successful SaaS sales cycle needs:

1. No Sales Rep involved during early and middle stages of sales cycle.
2. No technical people required to demo and setup until the close stage, which is possible if your product is self demoable and user can sign up for evaluation use online.
3. An application which can be provisioned and configured by the customer themselves, this being a basic tenet of what a SaaS system needs to provide anyway.

For item 1, what do you in lieu of rep to prospect face time? Viral marketing is one way - effective use of online networks with vocal customers evangelizing your product. It's all about building up trust. And if we've seen one consistent thing on the web, consumers trust other consumer's referrals more than anything.

To close the deal, you are going to obviously need some interaction, but that doesn't need to be time intensive, could be a couple of phone calls and a WebEx/Gotomeeting presentation.

Is SaaS a profitable business model? If you have built your product well, its easy to use, is self provisioning and self configurable and solves business problems, then the answer is Yes.

'Webifying' the Desktop

I have been reading some interesting blogs lately.

Treb Ryan
Bob Warfield

Treb makes the prediction that "All applications will be web applications".
Somebody like myself who is exclusively involved in SaaS will obviously agree with that point, although I would amend it to be "All applications will have a web component to them, will be deployed over the web and will have a shared information repository on the web"

Bob makes some interesting and valid observations about the future of the desktop and how it can survive in the web X.0 world.

What this got me thinking about was "what is good about the desktop which cannot be currently emulated in the browser".

Despite all the fantastic innovation that Web Developers have achieved, they still fall short of the user experience which the desktop can provide be it Vista, Mac OS or Linux. This could be due to the boundaries of the browser.

A lot of talk is about Mashups right now, a good thing.

However wouldn't it also be cool if on your desktop you had your dashboard from your SaaS BI tool displayed in one corner, your list of Tasks from your SaaS Scheduling app in another, a list of contacts from your SaaS CRM tool and then your Question and Answers from Linkedin at the bottom. You could then drag and drop items from one SaaS app to another. All the processing of data would be handled on the hosted app side and you are simply rendering UI results on your desktop.

There is still huge potential in browser apps but the desktop could still provide some interesting opportunities.

Web 2.0 again!! and Social Networking.

I actually read a lot of the questions coming through on linkedin.com via igoogle.
As we discussed in some of my earlier posts the term Web 2.0 appears to have different definitions depending on who you talk to.

On linkedin, everyone is talking about Social Networking and Collaboration and defining this as web 2.0. (Everything is X 2.0 nowadays as if by putting the number 2 in front of a term we have suddenly and miraculously discovered a new technology)

So now Web 2.0 is social networking which also includes collaborative tools in the business environment.I am an avid user and supporter of these types of tools being it a wiki, blog or networking sites like
linkedin.com

Less focus is placed on line of business applications being transformed by Web 2.0 in particular SaaS. My interest is obviously biased towards this, but I think the success of Web 2.0 collaboration tools within a business organization actually hinges on the adoption of a SaaS mindset first.

By having these SaaS business tools in place first, it gives context and sensible subject areas to Social Networking and colloboration.

A good example I think is Life Science CRM. I read an excellent post today
Scott Monty

Pfizer is partnering with a social networking site and will get access to the thousands of doctors who network there. Now this is something that the Sales reps would love to analyze and review for the zipcodes in their territories and the best place for this would be in their CRM system. Not an easy task if you aren't using a SaaS application. By having it in CRM, it structures what is essentially unstructured information. I can picture one day a Life Science SaaS CRM solution which has a social networking and blog portal for doctors as part of its feature set.
(Although you have to be in compliance with all FDA regulatory requirements.)

SaaS Product Pricing

Found an interesting question in LinkedIn a couple of days ago. Someone in my network asked about how they should price their SaaS offering to customers.
All sorts of complex scenarios were discussed and extra charges for infrastructure was suggested.

Frankly, IMHO that type of talk misses the whole point of why SaaS is attractive to many organizations. SaaS is not about technology or the platform, its all about a service that you pay for in a regular cycle. As a potential customer, If you get charged for infrastructure or server hosting, thats not SaaS, its an an additional unnecessary cost which you were trying to avoid in the first place with SaaS.

You look at SaaS because you don't want the higher cost of ownership of buying servers, software licenses and the additional cost of setup.

A secure and stable hosted environment is a given and a customer should not be expected to pay for that as an extra cost.

With a SaaS solution, initial provisioning should be transparent to you and pricing should be simple, a single per user monthly cost possibly on an annual renewal.