Enterprise SaaS != Web 2.0: A Quick Hosting Perspective

Sep 10, 2007 by

I like a good mystery just as much as the next guy, and this story’s got it all.  If you haven’t got the time or interest to read the whole forum thread, here’s the synopsis:  Jatol.com (no hyperlink provided because of said mystery), a notable web hosting company seemingly popular with development crowds has simply vanished.  Literally.  Websites down. Domain missing. Phones disconnected. Believe it or not, even the owner is missing

At this point, there’s not even a support number to call and Jatol.com users aren’t even able to retrieve their stored data or web site files. As I read further down the discussion chain, I started thinking about how awful it would be if I were running a web-based business in a situation like this – the mere thought of surmounting catastrophic shutdown such as this is mind boggling.

While it may seem obvious to some, this story specifically highlights a very important part of what enterprise SaaS ISVs should look for in managed services: providers that can assert serious service level agreements and back them with real ramifications.  For instance: transparent multi-tiered redundancy, consistent and thorough backups and archives, potentially even software and hardware escrow services (see ‘catastrophic shutdown’ above). The bottom line is that hobbyist devs hosting websites or even working applications with reliable hosting companies count downtime in minutes, while enterprise count downtime in thousands of dollars.

The tricky thing about SaaS is that it fundamentally requires the ISV to at least purport to be the ‘provider’ of software.  While hosting may be outsourced and ISVs become at least the ‘P’ in ‘MSP’, it is vitally important that the backing ‘MS’ be up to par.  If you’ve dealt with an MSP (without naming names) and had service level ‘experiences’, what are your thoughts on MSP preparedness for SaaS?  Are MSPs ready to host enterprise SaaS applications that generate the aggregate load of potentially millions of ISVs’ users?

[poll=6]

 

read more

SaaS Strategies for Existing ISVs

Aug 28, 2007 by

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

Why Do We Overcomplicate Technology Messages?

Feb 6, 2007 by

Generally, most of my posts introduce a topic, question, or label (we’ll call it x), and then I provide a y to describe and foundationally support x. Well, for this post I’m going the opposite direction. For this particular x, I find that the sheer mention of it causes people to cringe and howl. Instead, I’ll give you y first, and then x (kind of like Jeopardy, but not really, but kind of). Here goes y

Imagine a technology that lets you reuse other technologies you’ve already bought and built regardless of how these other technologies were made. This same technology will also make sure that any technology choices you make in the future can be easily integrated into your existing system.

What x am I talking about in the above y? Service Oriented Architecture, or vernacularly known as SOA. Ok, go ahead and cringe now. Why am I bringing up the continually beaten dead horse? Because to this date, I want to vomit while reading the various descriptions of SOA on the web (particularly those provided by SOA vendors). Is it really that hard to relay a simple message? I’m basically jumping in on Thomas Otter’s side, as highlighted in his recent post on SOA. It seems like there is a trend in overcomplicating messages within the technology. When you have an established technology or product, there is no reason to obscure or overcomplicate your message when marketing the said product. Apparently, SOA is a magnet for obscure definitions. Some examples:

“Service-oriented architecture (SOA) is an evolution of distributed computing based on the request/reply design paradigm for synchronous and asynchronous applications. An application’s business logic or individual functions are modularized and presented as services for consumer/client applications. What’s key to these services is their loosely coupled nature; i.e., the service interface is independent of the implementation.” 

-http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html

“SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners.”
-http://www.xml.com/pub/a/ws/2003/09/30/soa.html (To be fair, this one attempts to set-up a simple analogy before hand)

“Service orientation is an approach to organizing distributed IT resources into an integrated solution that breaks down information silos and maximizes business agility. Service orientation modularizes IT resources, creating loosely coupled business processes that integrate information across business systems. Critical to a well-designed service-oriented architecture is producing business process solutions that are relatively free from the constraints of the underlying IT infrastructure, because this enables the greater agility that businesses are seeking.” 
-http://www.microsoft.com/biztalk/solutions/soa/overview.mspx

One thing companies may want to consider is to follow Otter’s advice: “The way to talk about SOA is not to talk about it” or don’t define SOA with the word SOA, and don’t get all architectural on us. After all, what is more understandable: Peanut butter is a healthy, tasty food that goes well with grape jelly or Peanut butter, a processed form of Arachis hypogaea that maintains a creamed consistency, is a flavorfull food that is often used in a pairing with processed grape food and provides its consumers with antioxidants, monunsaturated fats, and Resveratrol, all of which are generally associated with fortifying the human body against cardiovascular and coronary-artery diseases. Personally, I like chewing on peanut butter and jelly, and not on mouthfuls of words.

read more

SaaS Provider Buckle Risk

Jan 30, 2007 by

Alarmist titles are great, aren’t they? In all seriousness, I don’t intend to take an alarmist position in this post. However, I do want to highlight something that we discuss at Apprenda as the “buckle risk” that SaaS providers must deal with.

Rapid growth, when used as a blanket term, tends to be associated with success due to the positive connotation of growth and the generally accepted positive implications of something growing from smaller to bigger. For example, rapid revenue growth is good for a company, correct? Not always. A classic problem is burning through cash to match the operational needs of rapid revenue growth, and not giving time for the bottom line to “sink in.” Have any of you ever read the story of the sports apparel company 180s? If you’re in any type of business, you should read this story if you haven’t. Outside of the business world, rapid growth can have negative effects as well: dogs that grow too rapidly as puppies frequently develop hip dysplasia, or cities and towns (or any populace structure) that grow too fast frequently experience difficulty maintaining quality of life for residents. Generally, all of these had one thing in common: the unchecked growth severely taxed available or existing resources leading to unexpected or unintended consequences. So what does this have to do with SaaS providers and what in the world is “buckle risk”?

“Buckle risk” is best understood as the risk a SaaS provider takes on when planning for growth of their subscriber base on an unproven/untested technical architecture and infrastructure. Growing your subscriber base creates a “double edged sword” scenario, particularly if you’re building and deploying an enterprise SaaS application. You need a large and growing subscriber base to attract larger customers, but if your base grows too big too quickly, you could end up with service hiccups that alienate (and shrink) your existing base. Worse yet, your hiccup turns into an all out “buckling” of your infrastructure that takes a couple of days to get working again. Enterprise customers don’t like this very much, and are much less forgiving than consumers. This forces you to ask many questions. Did you make the right data partitioning choices? The right architectural choices when factoring in scalability? How about your hardware infrastructure? If it’s in house, did you set it up well? If it’s outsourced, what sort of SLA do you have from your provider and can they handle your load? How large of a subscriber base can you support before you “buckle” and have to spend time and money adjusting: 5 thousand users, 10 thousand users, 20 thousand users? In the best case scenario, these problems affect your economies of scale and reduce your margins (which is not too good of a best case scenario, since SaaS is very much a margins game for the provider).

You’ll here responses on this topic of “We’d be happy to have that problem” or “We’ll figure it out when we get there.” Traditionally, this approach has worked; we’re all guilty of sacrificing load capability early on in a project for on-premise software because we can release a patch or tell the customer to cluster some servers together when it becomes a problem. With a SaaS architecture, releasing a patch of a certain magnitude can be far too expensive and risky, at least much more so than distributing a patch one-by-one to on-premise customers. Relying strictly on hardware scale-out/up can be pricey in the short term. Planning around this problem early, however, is the best solution. Look for ways to build or deploy SaaS applications that reduce “buckle risk.” If you’re a SaaS provider, is this something you’ve dealt with or are concerned about?

read more

It Costs More to Be a SaaS Company. How Platforms May Fix That.

Jan 25, 2007 by

Yesterday, Will Price of Hummer Winblad wrote a terrific quantitative analysis comparing the upfront funding needs of SaaS vendors, or application providers, with the funding needs of traditional software firms. In case there was any doubt, his data shows that funding a SaaS endeavor requires substantially more money – on the order of 3.65 times more capital, in fact. His article is titled “The Economics of SaaS: We Need a Platform.”

Mr. Price’s funding breakdown consists of data for publicly traded software companies in both the enterprise client/server space, and those that have reached IPO with primary SaaS offerings. His numbers add substantive clout to the prevailing, though often questioned, thought that starting a SaaS company or moving existing business to the SaaS model costs more than the traditional client/server model. Mr. Price deduces that the way to reduce SaaS development costs is to speed up development time – to get to revenue quicker. But how? Well, it’s no surprise that Mr. Price provides the platform as the answer. Solving the time to market and infrastructure overhead hurdles for SaaS vendors is what us platform developers refer to as ‘The Problem’.

read more