Transforming and Deploying Software as a Service – For ISVs

Jan 12, 2011 by Sinclair Schuller

For those ISV members of the SaaSBlogs community that might be interested, VMware has graciously invited us to participate in an awesome event that they have planned for January 27th. If you’re an ISV, and you’re contemplating a transition to the SaaS model, you won’t want to miss it! It’s a webinar specifically for ISVs, entitled “Transforming & Deploying Software as a Service“.

VMware is working with select partners such as Apprenda, to help ISVs deal with the specific complexities associated with Software as a Service. You’ll get a chance to learn how VMware’s virtualization technology coupled with SaaSGrid provides a foundation for delivering your software as a service. You’ll also get a chance to learn how other software companies are leveraging the SaaSGrid application server and VMware together, and achieving significant cost savings and time to market advantages over their competition.

We’re excited to be participating in the great event and we hope some of you will join us! Here’s a link to the a page with more information, the agenda and details.

EVENT DETAILS

Date: Thursday, January 27th, 2011
Time: 10:00AM PST / 1:00PM EST
Place: Online

Find out more now>>

On a similar note, I’ll personally be at VMware’s first ever ISV Summit during their Partner Exchange event next month speaking as part of a round table.  Feel free to reach out and let me know if you’ll be there and would like to meet up.

If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 3600+ members and is growing every day; make sure you’ re not missing out and join today!

read more

2011 Predictions for Cloud, SaaS, Multi-Tenancy and More!

Jan 10, 2011 by Sinclair Schuller

OK, it’s already 2011 and I’m a bit late on providing some predictions for 2011 – but now is better than never! I sat down and thought about events in 2010 and whether those events have created a meaningful disruption with near term potential to affect 2011 outcomes, and this is what I came up with. Some of it is based on intuition, some on knowledge, and some experiences I’ve had at Apprenda in working with customers, prospects, and others in the industry. This is more of a mental exercise in subjective extrapolation rather than “prediction”, so don’t hold me to these;-)

1)Adoption of SaaS by ISVs will pick up more steam in 2011

a.Overall, an overwhelming majority of Independent Software Vendors (ISVs) deliver their software via the on-premises “packaged software” model. Consumption of software as a service (SaaS) offerings continues to grow at an amazing pace, but most of the demand has been satisfied by a couple of hundred companies that have surfaced in the past 10 years as wild success stories, such as Salesforce.com. As a result, I expect that on-premises player will continue to take notice and make the switch.

b.Competitive pressures within major verticals are becoming more and more real due to successful SaaS entrants, which will drive adoption of SaaS delivery as a market response. Existing software ISVs will start respond by moving part of their product lines to SaaS, or by choosing to offer down-market offerings as an initial experiment.

c.Counter to the perspective of many experts, packaged software ISVs will find strategies that work in their transition to SaaS. Transitional “poster-children” of each vertical will give confidence to other ISVs in the market that the transition can be made successfully.

d.Continued adoption of new technologies such as platform as a service (PaaS) and cloud application servers will bridge technical gaps that will ease the overall transition burden, fueling adoption of SaaS by more and more ISVs. I do not think SaaS is the nail in the coffin for existing ISVs, particularly with technologies like SaaSGrid in the mix which flatten the technical curve for both new application development as well as migrations.

e.Continued explosion of mobile usage creates further pressure (and significant opportunity) for companies to move to a SaaS delivery model. Most business applications that have a mobile angle typically need back-end systems to reconcile the data into primary applications, and SaaS is the only architecture that makes this feasible at scale across many customers.

2) The Upstack Scramble Intensifies

a.Big players continue to make big moves to seize the opportunity to control the new software battle ground in the cloud. Traditional platform vendors will realize that the application development and architecture tiers are huge opportunities, and that infrastructure virtualization and infrastructure tier technologies are not the competitive landscape of the future. Deals like the Heroku and Makara acquisitions make a lot of sense for players like Salesforce.com and Red Hat, respectively.

b.2011 and 2012 will be a make or break years for these big players, and the moves they make over the next 12 to 24 months will ultimately determine the next decade of control and leadership.

c.Commodity players, or players that have become commodity, seek to buy value up-stack through acquisitions.

3) Real Traction with Private Cloud/Internal Utility Computing and SaaS delivery

a.Mistakes and failures experienced in 2010 will be the lessons learned to drive the real solutions and seed private cloud and private PaaS adoption over the next 12 – 36 months.

b.Organizations want a unified and scalable platform for software delivery, and the vision of private cloud will begin to include technologies that sit above the virtual tier to give significant architecture and services value to internal development assets. A paradigm shift in how software developed internally for business units will kick off.

b. Enterprise projects will continue to explore leveraging Cloud architectures such as multi-tenancy for internal use. The cost savings and agility potential presents enormous savings profiles that push their way into enterprise development shops.

4) Cloud Washing Reaches Critical Mass and Collapses by EOY 2011

a.After attempting to cloud wash offerings, a number of small and mid-market ISVs will close shop due to competitive pressures and no real tactical response. This will help identify cloud washing as a poor strategy and that only real, measurable attempts to convert a SaaS model will lead to success.

b.Forces vendors to articulate how their strategies and solutions that is unique and truly “cloud.” Continued success of pure-cloud/SaaS plays will evidence that cloud washing adds no value.

5) Force.com Starts to Realize Momentum Potential

a.Force.com/Apex’s stuttered start begins to gain true rhythm now that Salesforce.com has diversified its cloud to be competitive outside of its proprietary track, particularly in Ruby and Java arenas due to Heroku and VMForce.

b.Force.com will continue to show strong among those extending Salesforce.com’s CRM functionality and potentially within the enterprise where it can be used to displace situational “spreadsheet” applications.

6) Cloud Middleware Provides Democratized Access to Complex Software Architectures

a.General development/programming skills declining, coupled with a continued increase in architecture complexity creates a gapping void that new middleware needs to fill

b.Just like the years when desktop OS’ spurred innovation by enabling companies to focus on their software and not the underlying complexities associated with its delivery – new solutions will fill the gap and catalyze a similar era of innovation once again.

c.Middleware solutions like SaaSGrid will drive multi-tenancy as a defacto standard since the primary concern of difficulty and cost to implement is trivialized.

7) QE[pick your number] won’t be a panacea for the economy – but SaaS and Cloud will help

a.Economic factors will continue to put pressure on operating budgets. Companies will be looking to do more with less; that is, they’ll want to boost efficiency while slashing budgets in order to survive in the modern economic climate. Due to size, IT budgets will be scrutinized and IT managers will be challenged to come up with solutions.

b.SaaS will be seen as a means of democratized access to solutions that drastically improve efficiencies while driving down the cost of IT. Infrastructure as a service will be leveraged to reduce the operating burden associated with in-house infrastructure.

c.Doing more with less, optimizing business performance – SaaS based B2B solutions will grow significantly in 2011 as a result.

I’d love to get everyone’s thoughts. Agree/disagree? Why? Did I miss something or does this seem to cover the right surface area?

If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 3600+ members and is growing every day; make sure you’ re not missing out and join today!

read more

Salesforce.com’s Heroku Acquisition: A Clear Stake in the Ground

Dec 25, 2010 by Sinclair Schuller

Salesforce.com, over the past few years, has been reinventing itself as a platform company. IMHO, this is an extremely difficult thing to do for a company who’s cash flow is defined by the CRM market, an acronym that Salesforce.com adopted as a stock ticker. When Salesforce.com first announced Apex, it’s new fangled programming language and pseudo-stack, I took a highly critical stance because it was a clear attempt by a marketing and business team to tackle problems that only technologists can properly understand: building runtimes and frameworks that could provide a foundation for future software in the Cloud. My gripe was that Salesforce chose to create a new language that wasn’t rooted in a development paradigm shift where changes in a programmers ability to express solutions are the motivator, and instead decided to base the language development on seemingly more selfish interests and coupled the languages runtime to their operating and hosting environment. Essentially, they created vertically integrated lock-in, which is terrible for customers and the lack of purer motivations on the language development side produced a sub-par development stack best suited for small add ons.

Now we’re in 2010, and the story is starting to change, and seemingly for the better. At Dreamforce this year, Salesforce.com announced the acquisition of Heroku, the well known Ruby PaaS. Not too long ago, Salesforce.com and VMWare announced VMForce, bringing Java into the Salesforce.com cloud. Salesforce.com’s  evolution seems to be taking it down a path of stack agnosticism. This could be due to good strategic decisions making, or out of an attempt to correct a failed path with Force.com/Apex. Whatever the case maybe, its clear that Salesforce.com is embracing other stacks, and no longer focusing on creating a new $1 billion business by brute force.

It will be interesting to see where Salesforce.com goes with this. Will they make Java officially part of their Cloud by folding up a partnership with VMWare and instead make a Java Cloud their own competency? Might they go after Microsoft’s base by building or acquiring a value proposition that targets .NET developers and attempts to attract that group (who own 40% or so of the development market share) away from Azure? Who knows how far they’ll go, but one thing is clear: the Heroku acquisition clearly signaled that they want to do something different, and that something includes languages and runtime’s well outside of Apex. I really am glad that they’re adding true value and no longer beating the Force.com drum exclusively.

How do you feel about Salesforce.com’s Heroku acquisition? Any predictions on the success or failure?

If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 3600+ members and is growing every day; make sure you’ re not missing out and join today!

read more

Market Segmentation & The 3-Axes of SaaS Pricing

Nov 23, 2010 by Sinclair Schuller

Warning: This is a long but fun post!

Fellow blogger Lincoln Murphy recently put up a blog post titled The Dangers of One-Size-Fits-All SaaS Pricing Pages. I have a lot of respect for Lincoln’s focus on SaaS pricing because its something that is so overlooked by both new and mature SaaS providers. In this particular post, Murphy rails on the notion that, if you have an offering that spans wildly varied market segments, you can define a single pricing page that caters to all segments. I absolutely agree with Murphy. I think all SaaS vendors really need to understand their audience and their intentions when determining pricing and presentation of pricing. Some approaches can be counterproductive. For example, if you do have an offering that satisfies the needs of both upmarket and downmarket segments, or the needs of prospects in different verticals, putting all pricing on one page and using “plans” to differentiate can lead to the general dilution of the pricing message and result in poor conversion; a blatant jack of all trades, master of none issue. A pricing page should set out to do a few things: (1) is that the page should clearly disseminate pricing information and how that pricing information relates to the product experience and (2) the page should shoot for extremely high conversion. A pricing page is part of your marketing mix, and like any landing page calling visitors to action, it should focus on getting as many people through the door as possible. If the door gets too cluttered, confusing, or unwieldy, fewer people will walk through and trying to cram a message for each market segment into one page will undoubtedly flatten conversion.

So what’s the right answer to pricing? We had to think a lot about this when creating SaaSGrid since pricing and subscriptions are intimately anchored into SaaSGrid’s SaaS and multi-tenancy injecting runtime. I think to start, we need to define a bit of a formal ontology. First, we need to agree on nomenclature and hierarchy to define the parts that make up a pricing structure (note that I’ve abandoned ‘page’. ‘Page’ is specifically a presentation format, and has no bearing on a SaaS offering’s pricing structure. Pricing can be presented in a number of ways, ranging from a ‘page’ to a phone call). Once we provide for elementary definitions, we want to understand which parts of a pricing structure are ‘load bearing’ with respect to buying decisions such that we can best define pricing to address market needs. In my experience, there are a few major moving parts to pricing structures, defined as follows:

1. Components - Discrete aspects of a SaaS offerings function and/or form that are activated through entitlements that must be purchased. These entitlements may carry with them specific configuration that will influence the general behavior of said discretized functionality. For example, if I have a CRM offering and I want to charge for reporting, I may have a ‘Reporting’ component in one or places of my overall pricing structure. Furthermore, I may provide quantities such as the number of reports that a user can generate should they have this entitlement.
2. Plans – Composite structures that capture baseline pricing mechanics (such as whether a pricing model is user across time based – e.g. per user per month – as well as actual cost per model) and couples those baseline mechanics with component configurations. Essentially, a plan is an aggregate of zero or more components coupled to a base pricing structure. Furthermore, a plan may go on to specify component inclusion rules such as whether a component is included in a plan for any charged base fees, or whether a given component carries additional charges. For example, my same CRM product may have two different plans; one includes 4 components and optionally offers 2 others for additional fees while a second plan may include all 6 components as part of some baseline charge. Plans are the pre-purchase constructs that yield subscriptions upon purchase, where a subscription defines an end user’s sum total entitlements in the SaaS offering.
3. Pricebooks – A pricebook is the next level up in the heirarchy; it is an aggregation of 1 or more plans. Specifically, a pricebook is a group of plans in a sequential structure that indicates some sort of plan inferiority/superiority relationship. Furthermore, a pricebook may abstract away cross-plan configuration, such as currency definitions, generalized information such as footnotes, etc. For example, I may have a pricebook that aggregates the plans”Starter”, “Professional”, and “Premium” in order, respectively. This logical ordering defines an  evolutionary path for an end users progression through a product usage maturity model, and organizes those plans in such a fashion ass to help an end user assess the direction and magnitude of said evolution. A pricebook is an abstract version of Murphy’s ‘pricing page’; that is, a pricing page is merely a way to visualize a pricebook.

I could definitely expandthis definition even further, and in fact, we’ve gone much further than this at Apprenda. I think for the purposes of this post, we have enough formal structure to continue. (Just to add some perspective to where we could go with this, other formal structures can be added to the mix such as discount matrices which are defined as pricing perturbations that can be projected onto plans and/or entire pricebooks.) Visually, we can think of the aforementioned structure as follows:

(bigger)

So now that we have a generalized structure for SaaS pricing, what next? Interestingly, our pricing structure helps us in expanding our Served Available Market (SAM), boost pricebook consumption to customer conversion, and increase overall Customer Lifetime Value (CLV). Components, plans and pricebooks each define an axis on  a 3-axis pricing architecture.

(bigger)

Let’s think about each of Components, Plans, and Pricebooks along their respective axis and discuss how they optimize key parts of a SaaS business:

1. Components - Let’s assume we have only 1 plan in 1 pricebook; that is, we offer only 1 general way to purchase access rights to a SaaS offering within a single market segment. Using components we can define a la carte items. We might include certain features and functions as part of paying a base fee for the plan. However, this is our opportunity to really boost the amount of revenue we extract from the customer. Typically speaking, in any offering, there are features and functions that customers see much value in, and would happily pay an upcharge for. As a SaaS provider, this is something you can capitalize on. Within a plan structure, you can use components to selectively carve out capabilities in your SaaS offering that will have a high propensity of being purchased, and attach a premium to those components. This will drive up gross account value, and tilt CLV calculations in your favor. Far too often, people simply “throw things in for ‘free’” in a plan in hopes to create appeal. In reality, understanding what your customers value and leveraging components to create clean up-sell models can positively impact your bottom line.
2. Plans - Within a given market segment, you may find differences in the constituents. For example, power users vs, non power users, or the “I get 80% of my value from 20% of the software” folks vs. the “that one time I need feature X is worth all the money I spent on having that functionality” folks. Plans give you an opportunity to aggregate components into groupings that best calibrate around different personas or demographic sub-segments. This gives a SaaS provider the ability to boost conversion by creating profiles that deviate slightly from one another but that show the prospects that you understand who they are and that your offering can be well tuned to their specific situation. This even goes so far as understanding budget cycles. For example, a non-power user plan might be offered monthly and in no other way since typically non-power users might not have high signing authority, while you offer yearly plans to power users who typically come from a profile within a market segment that can sign off on thousands of dollars. This boost in conversion will prove to create a better utilization of marketing dollars and cycles. Echoing Murphy, you shouldn’t use plans where deviations from plan to plan are drastic (such as making plans that focus on different verticals, say Logistics and Healthcare) because it creates extreme noise that will probably flat line conversion. Think marketing, messaging, and homogeneity in plans that are part of the same pricebook.
3. Pricebooks - A SaaS pricing strategy need not have just a single pricebook. Pricebooks can be used to capture slighted different but generally homogeneous plans into a single structure. However, if you need to target different verticals, different geographic regions, etc., you need multiple pricebooks so you can deliver a consistent experience within the target. By doing this, you can effectively offer prospects entitlement purchase rights that reconfigure your SaaS offering for different verticals. Multiple pricebooks help you tackle these cross-segment challenges such that you increase your effective SAM as a result.

Optimizing along each of these axis such that you maximize the results of each axis within whatever constraints you are working with will typically yield a revenue and profit maximizing pricing strategy. It’s critical to truly understand what to expect from certain changes in your pricing structure so you can properly set expectations and run pricing experiments. Depending on where you take certain optimizations, you can expect different results:

(bigger)

Clearly, we’d all love to reach (Cmax, Pmax, Bmax) to have the ultimate super pricing, but that isn’t always realizable or practical constraints get in the way. Each SaaS ISV needs to understand what they are working with and where they can get the most bang for their buck. Regardless of your particular situation, having a grasp of a formal structure can go a long way.

How have you tackled pricing experiments? Did you think about conversion, SAM and CLV, or did you take a more generalized approach looking for top line affect? Do you agree or disagree with this ontology? I’d love to get your feedback and input!

If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 3500+ members and is growing every day; make sure you’ re not missing out and join today!

read more

Lack of Multi-tenancy: A Broken Business Architecture?

Nov 4, 2010 by Sinclair Schuller

A couple of months back, there was a rekindling of good debate around multi-tenancy, it’s importance (or lack thereof), and who benefits most (if at all) from multi-tenancy. Cost angles as well as soft dollar angles were discussed, as was a good overview of the importance of multi-tenancy being represented in the aggregation of data into a single, digestible source and the value that creates all on its own.

For anyone who has read SaaSBlogs before, you probably know that I’m a passionate supporter of single instance, multi-tenancy as the architecture of choice in most situations (there are some good edge cases). Clearly, I side with the proponents of multi-tenancy in most of these debates, but I want to tackle something different this time. Typically, the supporting evidence is anchored on cost savings and efficiency that multi-tenancy brings to the table. Let’s look at the multi-tenancy discussion through a different lens: that of a business architecture.

We rarely consider the ramifications of software architecture decisions on fundamental business processes. Most software to date has been developed in a vacuum because the cost of operations and delivery have typically been borne by the customer, not the software company that created the product. I find that SaaS vendors are surprised when I discuss their technical decisions in terms of how it impacts their ability to sell in a most real sense. Let’s start with a simple example: offering free trials or running a beta program.

Free trials are used to provide prospects with some sort of evaluation period of your software so that they may make an informed buying decision. Beta programs give prospects and existing customers early access to new offerings, or to changes in existing offerings existing customers already subscribe to. In the on-premises world, this was a simple thing to do because you shipped bits to customers at no cost to you. As a SaaS provider, things are different: for both of these use cases, the SaaS provider must bear the incremental cost of delivery of each prospect or customer that asks for a free trial or entrance to a beta without associated revenue. The SaaS provider, being responsibility for delivery, now takes on the full operating burden that the customer used to take on to run an on-premises free trial or beta.

Now you ask “Sinclair, so where does multi-tenancy fit in?” If you understand multi-tenancy, you know that it drives up the ratio of the number of customers that fit on a given physical or virtual infrastructure by forcing resource sharing within application stack components. A “tenant” is a meta-construct that does not require physical boundaries for isolation. This means that the incremental cost of acquiring a new customer is as close to $0 as possible, and can remain at $0 if the customer posts little activity. Everything from your Oracle/SQL Server licenses to your physical or virtual infrastructure costs are spread across customers. A single instance per tenant model, even in a virtualized case, is severely broken in this respect. Let’s use a more concrete thought experiment to understand this.

Let’s say that we decided to use Amazon’s EC2 to virtualize our offering to provide for tenant isolation; that is, we create an EC2 virtual machine instance for each customer to our SaaS offering. As of the writing of this post, a small Linux EC2 instance costs $0.085 and a small Windows EC2 instance costs $0.12. Let’s use this and some other assumptions  to build a model to understand what free trials in a non multi-tenant world due to Customer Acquisition Cost (CAC) and the payback period of the CAC. Since Apprenda is in the .NET world, we’ll focus on Windows instances. This means that for every hour of a free trial we run for a single prospect, we pay $0.12. Offering a 1 month trial is quite typical. Now let’s assume that a customer earns us $250.00 in monthly revenue (for the sake of realism, maybe we earn $50.00 per seat per month, and the average deal size is 5 seats). Furthermore, let’s also assume that for every 20 prospects that try our SaaS offering, 1 decides to buy, giving us a 5% conversion ratio. Our model would look as follows:

(bigger)

Since our conversion ratio is 5%, the increase in cost for acquiring a single customer is $1,752.00 in the Windows case! Where does this number come from? Well, there were 19 trials that did not convert to paying customers. Running a 1 month free trial for those prospects cost $87.60 a piece!. The revenue generated by the single converted customer must account for the money spent on the 19 lost prospects. To add even more perspective, if we are generating $250.00 in monthly revenue from that customer, you’d have to keep that customer on board for 7 months in order to recover the money spent on CAC. In fact, that’s being kind and saying that every dollar of revenue can be spent on recovering CAC. This is incorrect, because in reality, you’d have to keep spending $87.60 per month for that EC2 instance for your new paying customer, which needs to be taken off the top of the $250.00, with gross profit applied to CAC recovery. This would stretch out to over a year, and we haven’t even accounted for the remaining customer acquisition cost (you know, the sales and marketing dollars you spent attracting new leads and closing deals). This is not feasible! Sure, you could shorten the trial, maybe ask the customer to foot an evaluation bill, or boost conversion by double, or all of these. At the end of the day, those are all extra hurdles  you could do without, and would be a band-aid that would simply reduce the pain a tiny bit.

Even on the LAMP stack, the results are terrible. You save a couple of months on CAC recovery; big deal. The fundamental problem is that this sort of “architecture” is not built for a more sophisticated delivery model, and “throwing hardware at it” is costly. Lacking multi-tenancy could really cripple your business architecture. This is just the tip of the iceberg. Things that should be simple, like effectively rolling out upgrades, managing orphaned trials, being able to build a revenue stream from data aggregation, are all hampered. We could probably find lots of ways that an ASP approach breaks down your ability to run a business or tune your sales and marketing, but this simple example seems to work as a good illustration of the types of problems to expect.

This topic is close to my heart because of SaaSGrid. As most of you know, SaaSBlogs isn’t really a place where I try to plug our platform, but it’s just so interesting to think that our customers don’t have to worry about multi-tenancy as they can inherit a single instance, multi-tenant architecture from SaaSGrid and avoid these problems without having to spend an additional 6 or 7 figures and 10 or more months in additional project time to get this sort of architecture like some of the older SaaS companies had to achieve good results like this or being able to show people how SaaSGrid can rollout an upgrade across 40,000 end users and a few thousand customers in a matter of 8 minutes because of the multi-tenancy it can inject into otherwise plain web app architectures.

As a SaaS provider, have you experienced similar results painted in the thought experiment? Have you considered issues like this prior to architecture planning? I’d love to hear your thoughts!

If you’d like to mingle with others in the SaaS space, the SaaSBlogs group on LinkedIn now has 3500+ members and is growing every day; make sure you’ re not missing out and join today!

read more