A Future of Cloud Stacks or Cloud Silos?

May 11, 2010 by Sinclair Schuller

When thinking of the cloud, there are two sides to the coin: those who build SaaS offerings and those who consume them. For those who build SaaS applications, we’ve seen a glut of tools crop up to help engineer, architect and deploy SaaS offerings. Some are “horizontally” aligned (think EC2 on the IaaS side, SaaSGrid on the application server side, etc.) while others are “vertically” aligned holistic silos (think Force.com on the PaaS side – even with the recent VMForce announcement) and some are in a mid-silo middle (think Google’s AppEngine and Microsoft’s Azure, both “up to the runtime” PaaS stacks).

Given that there is so much velocity, tumultuousness and general confusion (acronym hell coupled with taxonomical conflation – aka the “everything and everyone is a platform” syndrome), we’re bound to see some order evolve in the future where the evolution will be motivated by what people actually use and adopt rather than the current landscape which is driven by who can yell the loudest.

The big question is what will the future of cloud architecture look like: a stack of interchangeable layers that allow one to choose best of breed or a group of incompatible but highly specialized “holistic silos?”

Looking at the history of infrastructure middleware, the answer seems to be quite clear. Typically, the trend has been that layering functional best of breeds into stacks provides the best combination of “lowest common denominator” coupled with the necessary functional value to “get things done” and keep risk minimal. For example, I can choose servers made by HP, a Windows OS, Java and JBoss, and build a killer enterprise app. If I so decided, I could have swapped Windows for Linux and essentially had a compatible stack experience.  Why, then, are silos cropping up in the market?

Silos like Force.com have their appeal. They promise a world where all your needs, ranging from hosting and execution runtimes in the cloud all the way through development frameworks and distribution channels. The problem, however, is that the software market cannot be addressed as a broad stroke.

The needs of software companies vary wildly: ISVs in the healthcare space may care more about hosting certifications than someone in the CRM space, while those in business intelligence need low latency, high compute availability and the others who altogether care very little about the hosting and it’s all about what middleware they are going to use. The number of needs permutations is staggering.

To think that Platform as a Service vendors that own the full stack, from hosting through runtime and even UI components, can ever optimize for each of these scenarios is ludicrous.  Furthermore, the silo providers ask for something huge in return for a suboptimal solution:  control of the ISVs destiny in all regards. That’s a high price to pay for a promise that can’t be fulfilled.

	Cloud Stack	“Half Stack”	Cloud Silo
Operations Management	SaaSGrid		Force.com, Quickbase
SaaS Middleware		Microsoft Azure, Google AppEngine
On-Premises Runtimes	.NET, Java, etc.
Cloud Infrastructure	EC2, Rackspace Cloud,  GoGrid

I’m a firm believer that most if not all software will be delivered online. It’s the only way to achieve true ubiquity, and it requires superior delivery. Each ISV is going to have to make lots of decisions as they move to the SaaS delivery model. Those decisions are going to focus on how to best solve all the critical problems associated with becoming a service provider. The only logical conclusion is that each ISV will look for best of breed tiers in a stack form that would allow them to create an optimized outcome. I don’t see a grand future unfolding where thousands of ISVs worldwide commit to incompatible silos that require taking on relationships that amount to single points of failure and risk. As a stack becomes more vertically consolidated (i.e., more siloed), the higher the risk grows for an ISV. If ISVs take on piece-meal stacks composed of highly compatible tiers, the walk away with the best of both worlds.

What do you think? Do you think that the next generation of business applications will be split across walled silos, or will the market adopt levels of commonality by converging to a stack approach with solutions provided by a few key companies at each layer, allowing for a “composable” stack approach that we’ve grown accustomed to?

read more

SaaS Adoption’s Secret Weapon: Hosting Providers

Feb 4, 2008 by Sinclair Schuller

It’s common place to discuss SaaS adoption as being driven by either an ISVs need to remain competitive or tackle new markets, or by customer demand to move responsibility away from internal IT to an outsourced provider. I support this as being very true, and we can thank these two constituents as being the driving force behind recent adoption. But is that all of the muscle that the SaaS movement has? Absolutely not.

Two constituents that care the most, and bring a lot of strength to the table, are enablement companies like Apprenda (our company), and application hosters (not really a ‘word’ but we’ll make it part of the post’s vernacular). Hosting companies/managed application providers are often overlooked or underplayed when discussing SaaS. Generally, the world of hosting has become a collection of relatively bland offerings with focus on “old style” services (although there are atypical cases). Most hosters are looking for a new value proposition that can move them out of a low margin commodity and back into the lime light. Building a business around SaaS alleviates the “low margin” problem and if hosters spend more time and money taking SaaS more seriously, they may become SaaS’ next champion. The more ISVs and customers they can attract, the more they can extract from this high value market.

I don’t believe SaaS adoption is set to halt by any means. In reality, I think there is still plenty of room for adoption via a collective championing of the delivery model by hosters who are looking to leverage their multi-million dollar infrastructure investments and pump up that good ‘ole revenue dollars/deployed infrastructure ratio!

Do you think that hosters can play a larger role in driving adoption? Do you see the next stage of SaaS innovation coming from hosters?

 

read more

SaaS as Recurring Revenue Justification

Nov 20, 2007 by Sinclair Schuller

One common misunderstanding (at least in my opinion) I find when discussing SaaS with people (particularly SaaS vendors) is that they make statements like “SaaS is nice for business because it’s recurring revenue.” Why is this a misunderstanding? Well, the way that statement is framed is that SaaS gives the SaaS provider the benefit of recurring revenue. Instead, the topic of recurring revenue and SaaS should be framed under recurring payment from the consumer in exchange for recurring, high quality delivery of software functionality. It makes the issue seem much less one-sided and is a more accurate representation of what happens (Yes, I have a penchant for definition nuances)

A recurring revenue model, however, is exactly that: a revenue model. Conceivably, I can sell someone on-premise software and ask to be paid $500 a month for the use of the software as long as it is being actively used. Conversely, I could have a SaaS offering and sell it on the basis of “Give me $50,000 and up to 6 users can use it forever.”  There is no direct coupling between the delivery model and the revenue model and with some craftiness I could use any combination of delivery and revenue model. In essence, I can achieve the benefits of stable, long term, and predictable recurring revenue or the benefit of large revenue influx and good periodic cash position via perpetual license sales without worrying myself about how software is delivered. Technically, we have the following four combinations:

1. On-Premise, Perpetual License
2. On-Premise, Recurring License
3. As a Service, “Lifetime License” (a re-labeling of perpetual to fit the SaaS conceptual framework)
4. As a Service, Recurring License

So what then, is so special about the coupling between the SaaS delivery model and the recurring revenue model? From the provider perspective, it makes the recurring revenue model an easy sell since its justified. It’s tough (although possible and has been done before) to sell an on-premise license on a recurring basis without any sort of continued, measurable participation from the ISV. The real importance of coupling SaaS with recurring revenue is actually from the consumption side of the equation. Those who use SaaS offerings get to pay as service is delivered, with the ability to discontinue use and mitigate losses when service becomes subpar or the offering no longer provides adequate return. Moreover, it also keeps providers honest and overtime keeps service quality levels high. This is a huge selling point that is not stressed enough and is significant in the SMB space since the cost associated with migrating to a new substitute SaaS offering is relatively minimal in nature and low in risk. When prospective or current SaaS providers discuss SaaS, stress should be put on the fact that “SaaS gives my customer the ability to pay as they receive service and have quality guarantees in place” rather than “I get recurring revenue” Customers don’t care if you get recurring revenue, but do care about the rest.

Do you think that SaaS is necessary justification for recurring revenue, or could recurring revene models be justified using “old” on-premise delivery/other delivery models? How important do you think “pay as service is delivered” is to SaaS customers?

 

read more

Are There REALLY Multiple Strategies for ISVs?

Sep 4, 2007 by Sinclair Schuller

About a week ago I wrote an article on SaaS strategies for existing ISVs, and I see that a a parallel conversation emerged starting with a post by Anshu Sharma that claimed that in the real world, ISVs “…adopt a range of delivery model options to fit the customers need and economics of their particular business.” Phil Wainewright followed up with this post, where he vented about Sharma’s position.

I wanted to post a couple of notes on this little blog battle. First, I think the problem with Sharma’s approach is that it’s strictly customer centric. I’m the first to agree that there are (and rightfully so) a multitude of strategies (as I mentioned in my prior post), but that the decision of which to choose should be a combination of what your customer base wants/needs and what aligns with your company’s future goals and anticipated market shifts. That said, your customer might say “I want on-premise”, but you see that the market is quickly changing, with early adopters going for some new delivery model (SaaS) and its probably only a matter of time before the mainstream market (your current customers) buy into it. If you were to listen only to the customer base, you’d find yourself in trouble in the near future.

If you dig through Wainewright’s post, you’ll notice that he does agree with multiple strategies when it comes to transitioning to SaaS. This is the position I take. None of the strategies I mentioned in my above referenced post are to be permanant. Rather, their purpose is to help an existing ISV make a strategic shift toward adopting SaaS. If Sharma’s intent was that adopting a wide range of delivery models should be/can be permanant, I disagree. That’s asking for trouble when it comes to scaling the business, building new efficiencies, and having a cohesive mission.

Bob Warfield jumped into the battle with this post, where he ends on a note of a “protected game preserve” which is basically a market defined by specific attributes (size of company, etc.) where you are free to play as a SaaS provider, insulating you from the dangers of a head first mentality. This is a smart approach, and is virtually identical to my concept of pursuing a “lite” version of your product that targets a degraded demographic, giving you an opportunity to “sandbox” SaaS while you figure things out.

What do you think? Is it healthy for ISVs to pursue permanent mixed delivery models, or does this create a “dysfunctional family”? 

 

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