Goldman Sachs recently released their take on the SaaS market from an investment perspective with a report entitled "Getting SaaS savvy—successful investing in on-demand." A summary of the report can be found here. In it, they list their scorecard for evaluating SaaS applications, specifically, how well suited an application is for delivery via a SaaS model. I thought I would go through each point and give you our take:
"The data used by the application either originates outside the firewall or goes outside the firewall at one point in time. If
the data is already traveling outside the firewall, this reduces
additional concerns the company would have had with the data security.
Having the application outside the firewall may also make access easier
for all parties who need to use it."
Boomi View: Disagree. Talk about taking the easy way out! Yes certainly the conversation is easier when this is the case, but this is not a requirement for a viable SaaS application. Take a look at the kind of data stored in the applications provided by salesforce.com; information like who your customers are, what you have sold them, how much they paid for it, how happy they are, etc. This information is some of the most guarded information a company has, absolutely vital to its operations, and does not originate outside a firewall or go outside a firewall in a non-SaaS CRM.
"The application is used by a distributed workforce and non-badge employees.
The ubiquity of Internet and Wi-Fi connections is making it easy to
access on-demand applications on the go, driving adoption of this
technology. By hosting the application outside of the company’s own
network, customers can get help solving the issues associated with
compliance and identity and access management with users outside their
own company."
Boomi View: Agree, although if ranking these by priority this one is low on the list.
"A network effect is important. By hosting
several customers’ data in one place, some SaaS solutions are uniquely
positioned to take advantage of potential network effects. For example,
seeing security threat information across 100 customers versus just one
should provide a better view on the broader threat environment, driving
a richer solution for all customers."
Boomi View: Absolutely agree. This is a huge reason why multitenancy is so important. The first step is "hosting several customers' data in one place" as mentioned, but without multitenancy, you can't do much with that data. This is why "sticking your product in a data center and calling it SaaS" doesn't work; a mutlitenancy design fundamentally puts all of this data in one place opening the door to new views and insights on how customers use your application, and in return allows you to offer them insights into their usage as well. Take mint.com as a great consumer example, once you start using Mint for your personal finance management, Mint will tell you what people in your zip code spend on groceries, restaurants, gas, etc. Not possible without aggregate access to this information.
"Quick implementation required with lower upfront costs to defuse deployment resistance. SaaS
solutions can be deployed orders of magnitude more quickly than their
classic counterparts and for lower initial deployment costs. For
applications that need to be implemented quickly (to meet an impending
timeline such as review season or quarter close) this is an attractive
attribute. "
Boomi View: Agree, although what application doesn't need to be implemented quickly? This is just a fundamental point of SaaS; the SaaS delivery model allows for faster implementations, and is a huge value proposition in all application categories.
"The application needs very little or no integration with other applications. Currently
this seems to be the biggest barrier to SaaS adoption, in our opinion.
One customer we spoke with said, “The thing that is always a challenge
with Software-as-a-Service vendors is integration. It’s even a
challenge with Salesforce.” We believe that as applications are become
more standards based, with standard APIs and the like, this will become
less of an issue. For now, however, we would avoid SaaS focused
offerings that require too much integration."
Boomi View: Disagree. Obviously we are going to be biased here, but any business application that is transactional in nature stores any information about your customers will need integration. In the majority of cases, SaaS ISV's are taking a best-of-breed approach, focusing on delivering one application very well. This proliferates the need for integration. Using this point in the scorecard basically eradicates 90+% of current SaaS offerings from being viable investment candidates! I would agree that a SaaS ISV needs a strong integration strategy before going to market (this is the whole reason we launched AtomSphere), as customers are definitely savvy enough to bring up integration during the sales cycle, and no just saying "code to our API's" is not an integration strategy :).
Also, API standardization has nothing to do with easing any perceived integration challenges. EDI has been in the process of standardization for no less than 30 years and standards like ASC X12 are at best loosely intrepreted and at worst completely disregarded. And even if connectivity became completely standardized, this is still only 1/3 of what integration is. Integration is equal parts (1) connectivity, (2) data transformation, and (3) workflow. See Bob's great post on this topic here.
The application, in most situations, does not require heavy customization. The
architecture of SaaS solutions does not lend itself readily to
customization. These types of applications will likely remain
on-premise for the near term.
Boomi View: Disagree. Again, any business application that is transactional in nature or stores information about your customers will be customized. Strong customization is available, today, in the majority of established SaaS players. Further, if you are building on PaaS offerings like Force.com, your application will be "customizable out of the box" without you having to build all of that complexity yourself!
"Addresses a business process
that should embody a strict process and industry-wide best practices
are well suited to SaaS delivery as well. SaaS solutions have
limited ability to be customized, so companies that are looking to
improve their internal process by adopting standardized best practices
will be well suited with SaaS deployments."
Boomi View: Disagree, but for the same reasons as above. But I would add that, in fact, because of SaaS, companies can now for the first time build ad hoc applications in days to quickly prototype new ideas without having to involve developers focused on other strategic areas of the business. This point paints an innacurate picture that SaaS is this behemoth inflexible thing...in fact much of SaaS's existence is owed to the vast failings of on-premise software deployments that were just that.
"Require relatively little training. Intensive training is a hurdle to adoption, which, in the case of a subscription service, can lead to customer churn."
Boomi View: Agree, and would add that the way the training is delivered should factor into this churn. On-demand, self service training is the first step in ensuring your users stay up to speed on your products capabilities.
"Applications that can be readily adopted by an individual or a small department rather than a whole enterprise. Low
subscription costs and quick and easy implementation allows one or a
couple of people within a company to try the product easily, without
the need to run a budget by higher-ups. No minimum seat requirement
should also spur this type of viral adoption."
Boomi View: Agree, this one is critical. And if you think that this is the end of your opportunity with this customer, it is the actually the beginning. Once they see the value of SaaS and how immediate the value gain is, they will become internal advocates and your application will spread throughout the enterprise.
"Are not heavy computationally intensive/time critical.
SaaS solutions do not deal well with large amounts of data that need to
be processed and passed back and forth between the database and the
program. Over time, as speeds increase and bandwidth becomes more
readily available, this should become less of an issue."
Boomi View: Disagree. Sorry to end on a low note, but SaaS solutions do very well with large amounts of data that need to be processes and passed back and forth between the database and the program. Remember that much of SaaS borrows from consumer applications like Google.com and eBay, that process some of the largest volumes of data in the world. Amazon got so good at scaling their infrastructure for vast amounts of data processing that they now let customers have access to this same infrastructure via their EC2 and S3 services.
Being a firm believer of "getting in the ring", I would offer 2 points I think were missed:
The application can intially augment and ultimately displace a large customer base of primarily dissatisfied customers. Look for graveyards of product lines that were scooped up by companies who then keep the application on life support, increase maintenance fees each year, but don't innovate the product. You will find bitter customers screaming for new innovation. They will be skeptical, but because SaaS lets you "try before you buy" (if done right) they can try out the application, make sure it works for them, and then engage with your sales team once they are comfortable the solution will fit their needs.
The application benefits from collaboration. Ok yes they almost all do, but take even rudimentary examples like Google Spreadsheet, where you can have multiple authors reviewing and editing the same spreadsheet at the same time. This is fundamental difference between the on premise equivalents.
What else am I missing? Fire away!
