Is Multi-tenancy Just a Database Architecture?

Sep 7, 2009 by Sinclair Schuller

Most everyone that’s part of SaaSGrid has converations either with customers, industry types, media, etc. about multi-tenancy capabilities that we “inject” into guest applications that live on SaaSGrid. One common misconception that we hear people spew out is that  multi-tenancy “is just a database thing.” That is so far from the truth! While many typically think of multi-tenancy as data segregation, it’s in fact much, much more. Usually, folks that haven’t done it (multi-tenancy) don’t get it!

First, let’s look at multi-tenancy at it’s core. What we’re really saying is that we want each customer to feel as if they have their own application instance regardless of what instance orientation is being used (single instance, multi-instance, etc.) Let’s look at the holy grail of single instance, multi-tenant. What we’re really saying is that generally (this doesn’t fit all applications, but most):

1. Customers needs to login to some *shared* frontend.
2. Customers execute business logic on *shared* compute resources
3. Customers store/get data from a *shared* data stores
4. Customers use auxilliary systems to manage their presence with the service

Is multi-tenancy just a database issue? I hope at this point some level of obviousness has become part of the equation. Multi-tenancy means that you architect your front-end to fit the instance flavor you’ve chosen (in our case, single instance) so that UIs can segregate provisioning and UI rendering. Second, services layers need to execute against data for the correct customer in a safe fashion (so one customer doesn’t clobber another customer), which means we need execution isolation from a tenancy perspective. Next, data needs to be stored and retrieved correctly per tenant. Last, everything from authentication systems to upgrade engines need to understand tenancy and distinguish tenants from one another.

The footprint of multi-tenancy, when done correctly, is huge on an architecture (which also means you’re not using SaaSGrid;-)) One shouldn’t trivialize it as “just an extra column on some tables” because it’s far from that, so make sure you really understand multi-tenancy before tackling it, as it’s one huge iceberg!

read more

A retrospective from someone familiar with the SaaS ISV trenches

Mar 24, 2008 by Matt Ammerman

This post simply serves to provide a link to a post on another site, but I felt it very appropriate to shine the spotlight on a brilliant post by Ben Yoskovitz on Instigatorblog.com entitled ‘Lessons Learned Running A SaaS Business‘. While we tend to focus on the relative “newness” of SaaS, it’s always important to remember that there are people who have been approaching, solving, re-approaching, and re-solving the challenges associated with SaaS for some time now. Ben outlines some key points from a “looking back” perspective. Give it a good read, there are tons of gems throughout – especially for those building go-to-market strategies for SaaS products.

read more

How Complex Can SaaS Offerings Get?

Feb 14, 2008 by Sinclair Schuller

It’s common place to equate Software as a Service with CRM, HR, or other “business function” style implementations. Although these implementations are not simple by any means, they generally do not require the computational rigor of an offering that performs complex mathematical analysis or photorealistic 3D rendering. In fact, it’s rare to hear that a company is pursuing this sort of “non-traditional” SaaS offering.

A recent discussion across two blog posts (this one and this one) sparked an interesting discussion about the viability of the SaaS model in the computer assisted design (CAD) space. The discussion revolved around issues like data access and security, but an important takeaway is to highlight that discussions are cropping up regarding application types that were traditionally considered “desktop only”. We see people discussing CAD, and even Adobe talking about bringing Photoshop online.

It’s my opinion that almost any application can be brought online these days, and that making those applications work well is a problem whose solution is rooted in good software engineering. SaaS offerings need not be restricted to applications that serve only horizontal business functions, but can branch out into non-traditional verticals such as CAD. I would even go as far as saying that in many cases, online versions may “out feature” and “out value” desktop counterparts. Take CAD for exampe: can every architecture and design firm afford servers that can perform photorealistic rendering? Probably not, but you can bet that a SaaS provider along with a massive render farm can give that sort of value to anyone on earth.

Do you feel my take on this is too agressive? Is it too early for traditional “heavy” client offerings to move to the SaaS model?

 

read more

SaaS 101: The Drawbacks

Oct 16, 2007 by Abe Sultan

A while back I wrote an article called “SaaS 101: The Benefits” in which I discussed some of the benefits of the SaaS model for end users and software vendors alike. Of course, where there’s a yin there’s a yang, and so this article (a long time coming, we know) will explore the other side of the coin.

For the Customer & End User:

• No direct control of the data – One of the biggest hurdles to get over is the control of the data. Specifically, what happens when things go wrong? I’m sure every company trying to sell you a product will tell you that things can’t go wrong and that they will be there to support you for years to come. It is important that you ask the difficult questions: How safe is my data? Will I be able to download it? Will it be disposed of properly and safely? Can it be sold? Can anyone else host the application and my data? Will the application source be opened so that hosting can happen in house or by another provider? Stories of companies going belly up are not uncommon, and not only for SaaS companies but for traditional software companies as well. The only difference is that when a traditional software company goes under, the most you might lose is the years of support you were expecting from the vendor. When your SaaS provider goes under, deeper implications surrounding your vital business data have to be considered. 
• Internet connection required - I don’t know of many businesses that run without an internet connection these days. Nonetheless, it could affect your operations if you need to access an application and the internet connection is down.  A good set of companies are trying to solve this problem by allowing their applications to continue to work in a disconnected fashion for a period of time but at some point you will need to sync back up to the server. If this is a big concern for you make sure that your provider can address this need.
• Dependence on an outsider to run your business – In a big way, you are trusting an outsider to help you run your business, and if they are not keeping their end of the bargain it can really affect you. To keep it in perspective, these people are out there to stay in business and they do this for a living so arguably 95 out of 100 times they can do it a lot better than you could in house. This does not mean that you shouldn’t be aware of the implications so make sure you ask the tough questions.
• Security awareness – Another big hurdle is security. This concern is the umbrella that is home to the concerns above, as the common thread among them all is that they make you consider how “secure” you feel with SaaS. You are trusting your really valuable data to someone else. This can be a painful reality to accept but most security breaches occur because of disgruntled internal employees that end up selling or releasing the data when they are fired or when they quit, having your data managed and stored by an expert of the application is not a bad idea as long as they take it as seriously as you would. Again, it is in their best interest to do so but make sure you trust your provider the same way or more than you would trust your internal IT department and again, don’t forget to ask the tough questions!

For the Provider:

• Focus on customer satisfaction - This is one of those bad things that it’s good to have and makes great companies but we have to mention it anyways. SaaS providers need to focus on customer satisfaction month in and month out or they will lose their customers. They need to earn their customer’s business every month or they can simply leave. Contrary to on-premise deployments which are very costly and time consuming, if your customer is unhappy with the service he can up and leave at any time with very minimal cost. Some might argue that you can negotiate longer term contracts, make it hard to take their data and all other kind of shenanigans but if you ask me, it is bad practice and if you are not the best, then you better have one damn good reason why they should stick with you other than a binding contract.
• Harder development process – There are many different approaches to writing SaaS applications and they are outside the scope of this article but the bottom line is that there is a whole new set of things that you need to worry about when writing a SaaS application that you otherwise wouldn’t need if it were a traditional on-premise deployment. Things like tenant isolation, provisioning and scalability to mention a few could be a hard thing to tackle where you wouldn’t even have to think about if you were writing an on-premise application. Nowadays there are several companies working on “SaaS Platforms” including mine that make this a lot easier but none the less it’s something that you didn’t have to deal with before. For a great article on how to transition your company into SaaS read Sinclair’s article where he outlines a couple different strategies. Another thing that makes the development process harder is finding the right talent as the skill sets required are more advanced than for its on-premise counterpart but hey, who doesn’t enjoy a good challenge!?
• Compensation issues – One of the early problems for SaaS providers is how to maintain operations when there is only very little money coming in. Unlike traditional on-premise deployments where one deal could bring you $60,000 upfront and carry you for a couple of months while you close more deals, SaaS deals are MUCH smaller so initially it will be a lot harder to maintain operations unless you are properly funded so you can survive until enough money is coming in . Additionally the question of how you compensate your sales team can be a tough one to answer and can vary greatly depending on your offering. It might require you to offer higher base salaries and get creative with your commissions but without a doubt it can be one of the tougher operational questions you will encounter.  As an example let’s look at this scenario: Provider A sales an on-premise application for $2,500 a license. On a decent 20 seat deal they would bring $50,000 ($2,500 x 20) plus an additional $10,000 for support (usually 20%). Out of the $60,000 they would normally give anywhere between 1% to 4% commission to the sales rep leaving the company roughly $58,500 to run operations. In a comparable scenario where Provider B sales the same type of application as Provider A but as a SaaS application it will probably cost around $75 per seat so on the same 20 seat deal they would bring $1,500 a month taking over 3 years to reach the same $60,000 that the on-premise company received. You will need to come up with a good strategy on how to compensate your sales guys but at the same time have enough money to run the company.
• Success can be a problem – You’ve heard many times that being too successful is a great problem to have but in the case of SaaS it can literally bring you to your knees if you are not prepared. This goes back to my second point of SaaS being harder to develop. Things can grow out of control if the application is not architected properly and addresses scalability issues and your service can become unusable over time if it does not scale properly with the addition of new tenants. Make sure you don’t leave the hard decisions for later because you will run into a wall down the road.

After reading this article some of you are probably thinking “Damn, Why would anyone even think of getting into SaaS?!” But for the ones that are still not convinced check the benefits before making any decision. As with anything else you should always make a decision after you have considered all things good and bad.

What do you think? Does it make sense to jump into SaaS from end user and provider perspectives? Do the benefits outweigh the drawbacks? Or is it the other way around?

[poll=7]

We’d love to hear your opinions, so leave your comments!

 

read more

SaaS Strategies for Existing ISVs

Aug 28, 2007 by Sinclair Schuller

One of my favorite (and most important) topics within the software industry is how can an existing, traditional ISV move into the SaaS space. For competitive reasons or new market reasons, many ISVs want to release SaaS offerings but are unsure of the approach, implementation, and risks. Let’s face it: not all SaaS offerings come from new-fangled Web 2.0 companies whose names are portmanteaux or the result of a random dictionary search and as a result (not a result of naming, but of already having an established business;-)), they are faced with multiple dillemma’s including figuring out how to retune their sales team to a shift in license model and sales methodology. In my opinion, however, the most important aspect of go-to market for an existing ISV is cannibalization. After all, your Acme Software company has managed to reach $40 million in revenue via perpetual sales and although you recognize the need for a SaaS offering, how could you justify replacing your successful product if it’s going to slash revenue and profit, and reduce your competitiveness against newcomers who don’t have to deal with these issues? There are various strategies to deal with the go-to market issues related to cannibalization. I’ll outline a few in this post. Below is a summary chart, with slightly more detailed information later in the post.

(bigger)

Full Product Replacement: Full product replacement is defined as creating a SaaS offering to replace a soon to be discontinued on-premise product. Full product replacement allows for the complete encroachment of your new SaaS offering into your existing on-premise product and market, thereby yielding the highest level of cannibalization and putting “all of your eggs in one basket.” Many of your existing customers will jump ship because they either feel abandoned or don’t believe in/need a SaaS offering. Anyone who moves from the on-premise product to the SaaS product will do so at the expense of the top line, since now it will take anywhere from 2-4 years to yield revenue that used to be acquired in a single shot. (We’ll call the time period of when an existing client will match its perpetual license top line input via SaaS licensing as the equivalent revenue yield period (ERYP)) A large ERYP and existing customer loss will mean that you’ll need a cash war chest to weather the storm. So why pursue this strategy? Well, if pulled off it can be strategically rewarding. First, it signals to the industry that you clearly support SaaS, enough so that you’ll bank everything on it. This could be good for positioning against newcomers in your space who are “SaaS only” and may be critical in convincing the SaaS choir that you’re worthy of their business. Second, most of the planning is up front. Whether things succeed or fail, once the strategy is executed and some time has passed, you’ve absorbed all of your change early allowing you to focus on your product.

Complementary Offerings: This strategy is defined as creating one or more SaaS offerings that compliment your on-premise product. For example, if you sell an on-premise logistics solution, you may opt to complement it with a SaaS offering that provides multi-installation visibility, management and data integration capabilities that boosts your customers supply chain management value. This strategy is appealing because it does not alienate your existing client base, but instead exploits cross elasticity of demand since odds are that a decrease in cost for your on-premise product should yield more physical installations, thereby increasing demand for your integration complement. Furthermore, it lets you test the waters when it comes to selling subscriptions, still leaving incentive for sales people via perpetual licenses. The downside? Well, you haven’t become a “SaaS player”: While this is a good short to mid term strategy, newcomers with pure SaaS offerings may offer cost and value advantages to your client-base forcing you into a corner with your high priced offering. Generally, if the exit costs on your on-premise offering are high, you should at least be able to “farm the base” while you figure out your next move. Just be careful because a poorly implemented complement could rub-off on your image and your existing product.

The “Lite” Version: The concept of a “lite” version of an existing product targeting a downsampled demographic is a tried and true concept that is used in various industries. We see it used in industries including the auto industry (Hummer releasing the H3, Porsche with the Boxster, Toyota with the Scion brand, etc.) and even clothing (Armani through its A|X brand) How does it play into SaaS? If you’re an existing ISV with an on-premise product, creating a “lite” offering with a subset of features that will be delivered as a service is a powerful mechanism for introducing yourself to the market. It allows you to play off of your established brand and keep your existing customers, and similar to the complementary offerings strategy, allows you to freely experiment with the SaaS model without encroaching on your base and experiencing massive cannibalization. In addition, new customers will most likely respect your existing product. What’s the danger? Strategically, you have two choices. If you still consider your on-premise model as your primary model, you’ll end up at a competitive disadvantage to pure SaaS competitors since you’re likely to use the Lite version as the start of an “upgrade path” to the more robust on-premise version of the software. This is a poor long-term strategy that reflects your company’s true intentions and position on SaaS: that its merely a new marketing tool for you rather than a new business model. If you truly want to shift your company to be a SaaS player, your focus should be parallel development that will allow the “lite” version to mature into a more accurate representation of your on-premise product, giving you revenue to work with, an avenue for your existing customers to switch to SaaS without feeling abandoned by your endeavors, and a long-term goal of migrating your company strictly to the SaaS model.

New Product Line: Relatively self-explanatory strategy. As an ISV, you may have always wanted to tackle a new (although aligned) market via a new product. One option is to create a SaaS offering to tackle this market. Personally, I feel this strategy is a tough strategy. It doesn’t attempt to blend SaaS into your existing company strategy and vision, but instead approaches it from an “offshoot” perspective. Failure of the product will most likely mean abandonment of a SaaS approach since you have little tie-in to your primary business. What’s more concerning is what does success mean for overall company strategy? If the product was successful, and your still happy with your primary on-premise product and business, do you have incentive to plan for the future and protect your primary business via a shift to SaaS? Probably not.

Has anyone executed any similar strategies, and if so, what did you experience in terms of results? Have you executed different strategies from those listed when it came to getting involved with SaaS?

 

read more