What is VMForce?

Apr 20, 2010 by

If you haven’t heard, Salesforce.com and VMWare plan on making a joint product announcement on April 27th at http://www.vmforce.com. Clearly, this piqued the curiosity of many, including myself. Thinking about Force.com, Salesforce.com’s strategy around the platform to date, and VMWare’s activity and intent to become more entrenched in the Cloud, my best guess is that it’s an Infrastructure as a Service (IaaS) offering, and maybe some sort of Spring-based framework layer that’s tightly integrated with Salesforce.com. Furthermore, it might even offer the ability to run native Force.com code/apps on top of it (I could see something like Spring being used  to create a harness of sorts to load Force.com apps on a native Java runtime)

Force.com is a high order abstraction requiring the use of a new programming language and a heavily diluted (read crippled) runtime. As a platform for extending the CRM functionality of Salesforce.com, it’s an amazing platform. As a general purpose platform for business applications, I think it’s too trivial of a runtime (anyone who’s read this blog before knows my position on this). Most mid-large ISVs solve complex problems addressable only through mature, expressive languages and complete runtimes and stacks. VMForce might be a step in the right direction – so let’s wait and see!

PS: For the literalists out there, one thing I noticed is that VMForce.com describes  it as a “product announcement” instead of “service announcement”. Maybe it’s some sort of special VMWare on-premises integration to the Salesforce.com Cloud?

What do you think VMForce is all about? Any drastically different theories?

read more

Does “Self Provisioning” Make Sense for Your SaaS Company?

Mar 31, 2010 by

Yes! How’s that for a quick answer? In all seriousness, I believe this to be a “no brainer,” but I think the burden of proof is on me to describe why. I think it’s important to set context and work our way backwards to conclude that an axiomatic ‘yes’ answers the question “Does ‘Self Provisioning’ Make Sense for Your SaaS Company?” Where do we start: at the definition of service, an understanding of conceptual dynamics at play, and agreement on the effect of competitiveness on distribution, of course!

Service. Let’s assume that “service” can be broken down into three main processes: engagement, implementation and execution. Engagement is the act of committing to use a service (e.g., signing a home builder to build your next home or remodel your existing home), implementation is overhead required to initiate use of a service, and execution is the process whereby the service provider performs its intended “statement of work” to yield an expected, implicitly or explicitly agreed upon result. I’ll use these process labels in my little analysis of what I see in SaaS.

If we dig in more, when we think of “service” we usually think of scenarios where, for a fee, some external entity completes a task or series of tasks on our behalf and produces some intended result. Second, I would say that it is generally understood that the service provider and the customer have a fundamental point of “equilibrium” with respect to knowledge required to provide the service and the knowledge required to engage a service. Yes, the knowledge can be skewed in one direction or another (As a trivialized example, a customer who is a Hollywood Socialite simply stating “I want a nice house” vs. anyone else stating “I want a two-story colonial with a basement, geo-thermal heating/cooling, solar power, and manufactured with a steel frame” places a heftier knowledge burden on the contractor that will ultimately build the house, while also increasing the contractor’s probability of failure since no clear requirements were presented.)

Rarely do we think of scenarios that require significant amounts of effort on the customer’s part to kick-off the engagement. For example, which is more typical:

  • Having a contractor come to your house to provide you a work estimate based on his/her measurements and discussions with local officials.

OR

  • Having the contractor come to your house and tell you “Great, nice house. All I need next is for you to go off and take measurements of your house, identify any new structural components and provide measurements for those as well, take care of architectural drawings, and deal with the town all by yourself regarding requisite approvals, and then I’ll give you an estimate.”

Ok, I know, some contractors do that, but what was your first thought? That’s right: “I’m planning on hiring and paying you and you want me to do what?!?!” Same goes for almost any service. Furthermore, we don’t couple the act of engaging the contractor with implementation; that is, we don’t tie the decision to use a contractor with the act of going out with that contractor to a supply store to pick out construction materials like wood, nails, and insulation. In fact, if a contractor ever said “Well, while we’re working on a contract together, let’s go out and start selecting what we’re going to use” we’d run for the hills simply because of the sheer idiocy of the request on the contractor’s part.

We expect that the engagement phase will be as trivial as is common for that type of service; we understand what the service intends to do, we have either an implicit knowledge of what implementation entails or have explicitly extracted it from the service provider, and intend to commit to that service provider. For example, a contractor would be ecstatic if he/she could post an ad for a set of pricing tiers for kitchen remodeling based on kitchen size and style, provide evidence regarding quality of service and accept signed contracts from consumers who were looking for kitchen remodeling. Furthermore, if it was common knowledge that kitchen remodeling required that the customer gets involved to a certain level of depth (picking out appliances), no one would have issue with the implementation phase since it was expected and generally accepted as protocol.

Notice how I hedged with the wording “as is common.” Frequently, product and service providers feel that their customers are a completely naïve group that lack the necessary crystalline knowledge and fluid intelligence to comprehend what they offer. Usually what this means is that your product or service has not been distilled to the correct level and cannot be digested by prospective customers without your help.

I bump into lots of folks in my SaaS discussions and travels, and I frequently hear “well, we’re not really worrying about self provisioning at this point. Our offering is too complex anyway.” What seems to be the case in most of these situations is that the SaaS provider has not identified a clear separation between engagement and implementation. In most cases (there are a few exceptions) engagement is not a complex process, even if implementation is. Without a clear distinction however, the complexities of implementation bleed into engagement, giving the service provider a false signal. In the SaaS business, a customer engages with a service by discovering the service and committing to use it. One can commit to use the service (signing a contract, paying some money) without being able to necessarily use the full functional set of the service immediately (since they may need complex implementation). Provisioning is just a synonym for pursuing and following engagement through to the end. If you’ve clearly separated engagement from implementation in your application and workflows, I’d say there is little reason to not allow self-provisioning. With SaaSGrid, we built a system that could take any application and provide an out of the box “storefront” and self provisioning capability because of this belief. You want to leverage point in time emotions your prospects have. When a prospect browses your corporate site, and they think “Hey, I really think this is the right system for us,” to lose that positive momentum because you didn’t think about or build a self-provisioning system would be a terrible loss. Do you have a complex implementation that would require the customer to migrate data, go through specific tailoring and setup? Fine. Do it after they engaged and committed to your service.

Do you agree that nearly all SaaS offerings, if cleanly partitioned into engagement and provisioning pieces, should offer self-provisioning? Do you see significant advantages to not offering a self-provisioning model?

read more

Great Interview on the Benefits of Multi-tenancy

Feb 5, 2010 by

This is a very good podcast of Phil Wainewright from The Connected Web interviewing Rick Nucci, CTO of SaaS integration vendor Boomi on the impact of multi-tenant architecture on the operational cost of delivering software in a SaaS fashion.

Two choice excerpts:

SuccessFactors recently gave a speech, [by CEO] Lars [Dalgaard], talking about their architecture and their approach. They have something like over a thousand customers per physical server when you net it all out and aggregate it. Andthat‘s the marginal utility, that’s the scale that you need to get to — because you need that op-ex in your business as a SaaS ISV to be in the five percent type of range. And it’s not going to happen if you’re doing a per-customer expenditure.”

“And that‘s the marginal utility, that’s the scale that you need to get to — because you need that op-ex in your business as a SaaS ISV to be in the five percent type of range. And it’s not going to happen if you’re doing a per-customer expenditure.”

Continue reading the transcript or listen to the podcast here.

read more

Webinar: Building a SaaS Business in 2010

Jan 25, 2010 by

Building a SaaS Business in 2010 – An Inside Look at the Business Model and Operations.

On Tuesday, February 2nd the authors of this blog and some of our business partners will be hosting a webinar to illuminate some of the key considerations and challenges ISV’s face when looking to bring a SaaS offering to market in 2010.  This session will include a deep dive into the SaaS business model as well as the operational side of the equation and feature key insights and lessons learned from the frontlines of managing SaaS businesses.

Although the content of the webinar is less technical than our typical fare here at SaaSBlogs, we think many of our readers will find it to be interesting and valuable material.

Additional information and registration: https://www2.gotomeeting.com/register/197663259

read more

The Evolution of Software

Jan 14, 2010 by

This is my first blog post for SaaSBlogs.  My name is Devon Watson and I am the Director of Business Development here at Apprenda.  I have worked with SaaS since 2002 when I founded one of the first companies to attempt to deliver Business Intelligence software in an on-demand fashion.  Being a bit ahead of the curve I found that the company struggled to reconcile our SaaS business model with the realities and limitations of the technology platforms available at the time.  After a good run and achieving paying beta customers we eventually had to close up shop as the dot-com hangover sent funding sources running for the hills.

After that I spent 5 years as a Venture Capitalist where I worked with many companies founded on SaaS business models, but with really what amounts to a glorified ASP (application service provider) infrastructure left over from 6-8 years ago.  I have come to view this non-alignment of business model, infrastructure and operating cost as a fairly standard refrain across the software industry.

Last night I gave a talk on SaaS to about 100 members of the  NY Entrepreneurs Business Network and the NY BizSpark Meetup group at Microsoft’s office in New York (thanks to NYEBN and MSFT ISV Evangelist Gunther Lenz for inviting me).  We had a very good discussion around the progression of the software industry from Client-Server to Web Applications and the ASP’s of the late 90’s on to the current SaaS paradigm.  The changes to the leaderboard of the software industry at each step in the evolution were obvious to the crowd – Mapics?  Gone when 3 tier web apps came out.  Siebel?  Eclipsed by SalesForce.com.

 
People quickly understood how SaaS finally realizes the economies of scale and consolidated operations needed to make on-demand delivery feasible form the ISV.  However, many of the budding software entrepreneurs in the room were surprised to learn that getting a SaaS company off the ground is actually more expensive than in yester years, despite the more desirable end-state.  Of the handful of SaaS companies to have gone public the average cost of capital to reach that state was $76M….$76M!  This is due to two factors – the delay in revenue recognition inherent to the SaaS business model and the longer (and more expensive) path to market due to the complex underpinnings of a good SaaS delivery foundation.

Luckily, you no longer have to reinvent the wheel the way my first startup did 8 years ago.

read more