SaaS Blogs

[…] Early next year I’ll be presenting at an outsourcing ICT summit in Auckland. One of the people I have plenty of time and respect for in the SaaS space is Sinclair Schuller of Apprenda. Sinclair posted this excellent discussion comparing SaaS with other ICT process outsourcing. […]

Sinclair, good question!
The economy helps, but not enough.

I started a project about a Vertical SaaS: wine industry. I’m Pablo from Mendoza, Argentina.

From our market study, the principal concerns is about security and offline capabilities. Security due to business secrets. Offline capabilities because the SaaS offering affects their production line: We must ensure that the software will run even without the Internet.

Excuse my english.
Pablo.

Hi Sinclair,

I think specialisation drives differentiation and a premium. So does effectively narrowing your market. I think the need for scale is a much more likely reason why vertical apps haven’t emerged yet. That and the switching costs you mention

Sinclair,

I’m not sure I agree with the use of the term “outsource” in the context of hosted software. Outsourcing generally refers to allowing a third-party to perform a task you would generally do in-house. You can look at turning to a hosted software solution as outsourcing the management of the servers and the maintenance of the system, but that would be comparing it to the status quo in a deployed environment. The reality is, when you move to a hosted solution, you get all of your required functionality, but you remove the need to maintain your own servers and other infrastructure. You do not need to worry about outsourcing that function, it simply doesn’t exist anymore, from the standpoint of the client. This is a very critical distinction that is key to marketing SaaS applications in a market where deployed solutions are the leader (almost all markets, currently).

I do agree that decisions around vertical offerings are made with more care (read: longer sales cycles) than horizontal applications, even if the vertical application is a fraction of the cost of the horizontal application. This is primarily due to vertical applications generally being “mission critical”, whether that is to the enterprise or a single business line. Due to the importance of the application to the overall success of the organization or business unit, it will certainly come with more objections. That said, those objections will be raised whether the solution is deployed or hosted. The hosted solution will be met with additional scrutiny (scalability, security, disaster planning, business continuity, etc.), but those objections are well documented and if the ISV is prepared can be overcome quickly. Those objections are often nullified within the client organization when the hosted system truly meets or exceeds the needs of the vertical target.

I also think it is important not to downplay the difficulties of switching software vendors, hosted or deployed, vertical or horizontal. This is never easy and at the very least will be time consuming and disruptive to the organization; both of which have associated monetary costs. One of the arguments SaaS vendors consistently use is the fact that their product requires little or no initial investment and that if anything goes wrong or the client doesn’t like it, they can just switch or go back to their “old” solution. Thankfully this type of argument is trailing off, and could have stemmed from SaaS vendors themselves not feeling 100% convinced of the delivery model. Having some solid in-market time under their belts has changed that and we see a more confident sales force pushing SaaS products these days.

- Lincoln

Lincoln,

I’d say that’s still “outsourcing” in the general sense; if you consider that you perform some task to get software functionality to your employee base via your own infrastructure, via SaaS you’ve effectively outsourced the delivery of the software functionality to someone else with the side-effect of removing the need for an internal hosting infrastructure. I look at software strictly from the functionality they provide me: on-premise app A allows me to do word processing, as does SaaS offering B. Using B effectively has outsourced the delivery of word processing functionality to a third party.

While you’re correct (from my POV) with your position on vertical solutions, I’d disagree on your comment of objections being nullified, here’s why. Prior to SaaS, if you were a small vertical provider who wrote on premise dairy farm management software and sold it to a dairy farm, the farm would love to know you’re around in case they need support. However, if you went out of business or stopped improving you’re application, the dairy farm could still continue using the software since there was no operational dependency and needing a substitute did not matter. That’s why you can walk into many places (say a doctor’s office) and see them using software that may very well be 10 years and the original firm that wrote it is out of business, but they’re still content with the functionality. With a small vertical SaaS provider, out of business or poor service equals trouble for the dairy farm due to an explicit operational dependecy.

I don’t mean to downplay switching costs, but the switching costs needs to be framed in the appropriate context: if you are a large enterprise using a SaaS offering, switching costs are proportionally more expensive than for the SMB and are very large from the absolute standpoint as well. An SMB (and particularly micro-businesses or companies with ~20 employees) will maintain low switching costs because of the overall agility. Looking at the economics of SaaS, micro and SMB will make up the majority profile of the SaaS user base, so being aware of significantly lower switching costs is still valid.

The outsourcing argument is simply semantics as we are definitely arguing the same point. In fact, I agree with you that software is about the functionality and nothing else, and this is never more evident than in a vertically-targeted offering. From a marketing standpoint, this is exactly what ISVs should keep in mind. SaaS products should be differentiated ultimately on the functionality they provide, not the infrastructure or delivery differences. It is, by the way, the infrastructure and delivery differences that will allow a SaaS product to provide functionality vendors of deployed solutions could only dream about.

Generally, I feel that it is a bad idea for a SaaS product to compete with deployed solutions based on the fact that the SaaS product is hosted. By doing this, the SaaS vendor immediately draws attention to the potential problems with a hosted solution, without first showing all of the reasons the product is superior. Additionally, if your SaaS product is simply a feature-for-feature replacement for a deployed solution, and your only value-add is the delivery model, I’m not sure that is enough. Now, if you combine that with a pay-as-you-go licensing model, things become more interesting. If you combine the SaaS delivery model, utility pricing model, and a feature set that meets or exceeds the needs of the target market, you have a combination that is hard to argue against.

I should have clarified my position on common objections to a SaaS offering being nullified internally by saying that it doesn’t happen often. It does happen, however, and it generally happens when the SaaS product offers functionality that meets the needs of the client in ways the other solutions on the market, hosted or not, simply do not. When this does happen it is because the SaaS products are new, from-the-ground-up solutions and have taken into consideration modern requirements. When we begin to see existing solutions “ported” to a SaaS environment (difficult to do, you usually end up with more of an ASP-type solution), we will see products that really haven’t made that functionality leap that can overcome those objections without a fight.

I like what you said about the doctor’s office with a 10 year old system from a vendor who doesn’t exist any longer. It is so true and plays out in more companies than the software industry would like to admit. Few companies are really on the cutting edge and many are running their businesses on systems that cannot be supported or even restored if a catastrophic failure occurs. I see this as an opportunity for all software vendors and especially hosted solutions providers. Knowing that this is the status quo, and that the status quo is always your biggest competitor, you can formulate a plan of attack.

However, the ISV must know their market and the dynamics within to adequately overcome those objections, but there are certainly ways of accomplishing this. Obviously showing that the system is hosted within a secure data center with 99.999% uptime, that you have a full disaster planning and recovery system in place, and that you have placed your source code in escrow, etc. will help quell those concerns. If you are clever, these responses to objection could also be used to point out just how risky their current solution really is.

That said, I would also warn an ISV to be careful entering a market where the majority of companies have systems that haven’t been updated in 10 years running their businesses. While this might appear to be a very good opportunity, the trend toward the status quo is going to be very difficult to upset. Unless this market has a lot of new companies coming on the scene, there simply might not be much of an opportunity.

Well put Lincoln! I think you hit it right on with needing to battle the status quo (which is generally overlooked and a topic for a whole other discussion).