The Right Tools for the Job

May 29, 2007 by Matt Ammerman

Are today’s SaaS enablement technologies robust enough to support business to business SaaS?  It’s a question I ask myself everytime I am introduced to a new ‘mashup engine’ or ‘online SaaS IDE’.  Granted, there are some very impressive products out there right now, Bungee Labs’ BungeeConnect and CogHead for example.  But initial impressions aside – are these whole product enablement environments robust enough to support extremely high levels of customization? Multi-tiered integration? Legacy integration? Complex computation and data types, and the myriad other requirements of the world’s most powerful business software? Even Salesforce’s proprietary Apex language born from Java seems a bit limiting in terms of programming expressiveness.  Or so I’ve heard.

CogHead made a statement in their early advertising that has stuck with me for awhile now – they said [paraphrasing] that “CogHead wasn’t designed for computational fluid dynamics calculations”, instead spotlighting ease of use for the business individual. The idea: an environment to quickly build business process applications, and it’s so easy that anybody in your business can do it.

The problem I have is not with the ingenuity or inventiveness of these types of environments. I think there is a ton of very cool, and applicable, things that can be done with them.  But I feel they alienate one crowd that, well, we owe pretty much everything to – software developers and engineers.  Those that have been schooled and trained in the complex sciences of computer programming and application engineering.  Believe it or not, but these folks are masters of an art – because there is a significant amount of expressiveness that goes into architecting an application, writing code, and optimizing it.  Furthermore, business to business SaaS includes applications and services that fundamentally require a powerful computational platform and languages expressive enough to harness the power of that platform.  I spoke with a vendor the other day who is looking for the right tools to develop an online service that provides genomic computation.  Yes, that’s right – genome sequencing for researchers, on demand.  

Some of the feedback I’ve read and heard from developers who’ve gotten their hands on languages such as Apex leads me to believe that developers’ hands are tied – even if they stretched the technology to its limits there’d be so much more they’d want to do with it that it’s almost not worth their time.  They’ve spent years honing skills in the .NET languages, in Java, PHP, Ruby, in name your favorite programming language – and now they’re being handed Javascript-based online IDEs and proprietary languages and told to deliver enterprise SaaS applications.  They’re being told by managers to port existing client\server code to an on-demand architecture using tools that simply don’t match up.

The tools exist, and developers have been using them for years.  They’re experts.  Perhaps SaaS enablers should focus on bringing the existing developer toolbet to the SaaS world, instead of enabling the rest of the business world around them with brand-spanking new tools that limit and eventually alienate developers.  Frankly, I think the novelty of so-easy-your-manager-could-do-it development tools will eventually wear off and the business world will turn back to developers looking for programmatic magic.  But, that’s a whole other post for another time.

The point is, handing an enterprise software developer some of these enablement tools and asking for a business-to-business SaaS application is like handing Mario Batali an EasyBake™ oven and asking for a six-course Italian dinner.  No matter the amount of genius and talent involved, there’s only so much you can do with a 100-watt lightbulb.

 

 

read more

Running a SaaS Business Costs Money?!?

May 6, 2007 by Sinclair Schuller

Being in the SaaS platform space, one of my passions (yes, really) is to breakdown the SaaS provider model and figure out where costs are. The one area that is most intriguing is cost of revenue (CoR) - that is, costs directly associated with delivering the service to end users. This cost generally includes, but is not limited to:

1. Bandwidth
2. Hardware(Amortized) & Hardware Related Expenses
3. Operations Staff (if applicable)
4. Storage
5. Backup & Recovery
6. Licenses
7. Co-location (real estate, electricity, cooling, etc.)
8. Product Support

Basically, any cost that is proportional to and incremented with a rise in your subscriber base, is relatively predictable, and is directly responsible for service delivery is part of cost of revenue. Now, I’ve read blog posts and spoken with people that have made comments like “SaaS shouldn’t be very expensive, after all Web 2.0 is about starting companies in a capital efficient manner” or “Digg.com scaled to tens of thousands of users with only a couple of servers.” While I agree with those observations, they don’t really play into true SaaS. SaaS is not about applications with shoddy reliability, or about applications that have simple, repeated read/write transactions. SaaS is about stable, reliable, customizable, and robust business applications. As a provider to other businesses, you have an ingrained duty to provide fanatical (borrowed from Rackspace) service and uptime. These properties requirements do one thing and one thing well: they increase the cost of service. To drive costs down, you need to become operationally efficient, make wise architectural choices at both the software and hardware level, automate as much as possible, and meticulously maintain metrics. No programming language/framework combo (yes, not even the panacea of the day, Ruby on Rails) can save you from poor architecture, inability to automate, and nack for getting operations wrong.

So, as a provider, what does it cost to run a service? To answer that, we have two primary sources: (1) the financials of publicly traded SaaS companies and (2) discussions with some private SaaS companies. I’ll start with public companies. For public company’s I took a look at members of the SEG SaaS Index, including Taleo, Salesforce.com, RightNow, Workstream (not on index), and DealerTrack. I’ve extracted what they consider to be “Cost of Revenue” and generally have a description that goes like so:

Cost of application revenue primarily consists of expenses related to hosting our application and providing support, including employee related costs for network related staff, the depreciation expense associated with computer equipment and the cost of extra data center capacity.

Here is the breakdown for 2006 alone, accounting only for revenue and cost generated by subscriptions ($ in thousands):

 

As a percentage of revenue, there is a large amount of variation. TRAK is the only oddball because they factor in “revenue share”, which is some sort of commission paid to 3rd parties, thereby driving CoR up. The other data samples adhere quite closely to the aforementioned description. Interestingly, this provides some rudimentary evidence for economies of scale (factoring out TRAK): Salesforce.com has the highest revenue and best CoR percentage, with WorkStream having the worst and the other two falling in order between them.

Having had conversations with smaller, private SaaS providers, the picture is even bleaker. Many times, starting off requires a provider to overpurchase to provide availability and over-capacity, yielding CoR that is higher than revenues. Overtime, the companies I have spoken to begin reducing CoR as economies kick in, but even those in the $10 million – $30 million range are still in the 20% - 25% band for CoR. Delivering a SaaS application is not inexpensive.
This highlights something very important: the best in the industry manages 14% with others nearing 30%. Take that into account when analyzing your costs. Yes, costs have and will go down for things like hardware, bandwidth, etc., but remember that will means in the future, and that there is still uncertainty. Many SaaS providers are looking at utilizing service solutions such as billing or an entire delivery platform (disclosure, self promotion). The data above should give you a good baseline to work from when deciding if something is expensive or whether your projections are in-synch. If you’re a SaaS provider, is your CoR experience relatively similar? Do you factor in other things, or leave things out that I’ve included? I’m anxious to hear your thoughts.

read more

Explaining SaaS Trust and SaaS Platforms Metaphorically

Apr 23, 2007 by Sinclair Schuller

Although SaaS is in and of itself of a unique and powerful model of software delivery, there is much to learn from industry’s that have produced either perfect or imperfect parallels. When I say ‘perfect’ I mean one with a distribution concept that provides a metaphor for SaaS, while ‘imperfect’ is more akin to an industry that has a similar psyche or has equivalent emotional requirements. During SaaSCon, I heard many metaphors and similes tossed about to help clarify what various aspects of SaaS are. Two particularly caught my attention – one was provided by Treb Ryan, CEO of OpSource, while the other came up during the keynote panel I participated in.

Treb had used the banking simile (which has been used before, but I think it highlights the psychological end user/provider nuances quite well) as an imperfect parallel, likening the psychological and trust issues experienced by SaaS providers to those experienced by the banking industry in its early days. He asked the question (I’m paraphrasing) “Do you feel safer with your money under your mattress or in the bank?” Granted, most of us would answer “in the bank”. However, at one time many people felt that putting money in the bank was unsafe – after all, who better to trust with your money than yourself? Someone could burglarize the bank, your money is mixed in with everyone else’s, etc. Once the populous got over the “trust” issues, a complete reversal happened. People recognized that money in the bank was far safer than keeping it at home – and so was born the massive industry we call banking. SaaS poses many of the same trust and security questions, and very much like banking, will prove to be the better model. Now, I’m not saying that “since it happened over there, it’ll happen over here” but it is easy to see that trust issues are by no means insurmountable, and arguably, if trust can be established with money and other liquid equity, I’m sure it can be established with software and data.

During the keynote panel, a question was asked by an audience member that I ended up fielding (again, paraphrased) – “Do SaaS platforms parallel the telco industry where value is controlled across the entire stack by the telco, or is it closer to the electrical grid where value is at the appliance level, which taps into the distributed power.” The question posed a perfect parallel because of the nature of electricity distribution. My response to it was that the electrical grid provides the best parallel for SaaS platforms – SaaS platforms are responsible for providing the foundational aspects of service delivery and management (i.e. “power grid”) while each application defines the actual value to the end user (where an application is much like an appliance). For example, if I toast bread, my derived value, although powered by electricity, is provided by the toaster oven. When a user uses a SaaS application built on a platform like SaaSGrid, the end user value is provided by the application. So where does the SaaS platform fit in? Well, your toaster comes with a power cord – an interface that encapsulates certain expectation. That power cord and any corresponding regulatory mechanics tap into the electrical delivery grid to make toasting bread possible. With respect to telco’s, value (in present form) is generally introduced by the telco and no-one else. Cell networks tend to be closed, and new functionality is introduced by the telco itself. That parallel is not valid – at least not with SaaSGrid; a platform’s goals should not be to monolithically provide value to the end user, but rather to provide all necessary delivery mechanics to the SaaS provider. SaaS providers – the appliance manufacturer’s – know what their respective customer’s want, and can deliver appropriately. The most important thing to realize in all of this is that most toaster’s do not come with their own power sources;-)

read more

Build vs. Buy and Economies of Scale

Apr 19, 2007 by Matt Ammerman

When formulating the architectural foundation for a SaaS application, ISVs will inevitably encounter the age old build vs. buy decision.  SaaS enablement is hot right now, giving vendors a plethora of options on the buy side. 

Nick Carr has an interesting argument in support of the buy scenario – specifically urging vendors to buy into a horizontally aligned platform serving multiple vendor-instigated verticals because issues arising with subscriber usage and economies of scale.  The example Nick gives is Intuit’s TurboTax online, explaining how the service from this system ground to a snail’s pace because of the mad rush of Americans filing taxes earlier this week. 

A similar example would be the usage peaks that a CRM application will experience at the end of each quarter as sales are tied up at a frenzied pace.

As an ISV, if you need to provide high availability service but that service is prone to suffer unusual high peak times, having ‘anticipatory’ hardware lying in wait can be quite cost prohibitive.  So what’s the solution?  As in most cases, aggregation of resources leads to economies of scale.  Platforms provide that aggregation, normalizing the usage spikes across many vertically-aligned vendor applications.  As Nick puts it, the only way to do this is by sharing the resources with other companies that also need high availability service but whose peak times are different than yours.  It is simply a matter of economies of scale, and platforms are able to achieve these economies through mass aggregation of requirements and management of resources.

Platforms like Apex and SaaSGrid aggregate infrastructure requirements, and taking the solution a step further by providing guarantees of service at any point in time without ISVs explicitly having to build out an infrastructure or request a larger slice of the computing pie during high volume times (unlike an MSP scenario).

read more

The Complexity of Monetizing SaaS Application Usage

Apr 4, 2007 by Sinclair Schuller

I’ve been following a series of blog posts by Lars Fløe Nielsen, Michel Baladi and some other folks from Microsoft, Sitecore and other firms. The posts follow a proof-of-concept project established by the firms to investigate how a “SaaS Hosting Platform”, or SHP, ought to look like. I appreciate the effort that has gone into this, and it really hones in on what is important to what parties in a SaaS ecosystem (ISV, hoster, end user, etc.) One particular post that caught my eye was this one. In it, Nielsen describes metering and billing constructs that would be handled by the SHP, as coordinated by the ISV during the definition phase of monetizing the application.

This post is interesting simply because it shows how complicated SaaS monetization, metering and billing can be. Some applications will have “simplistic” scenarios of a flat monthly rate with little variability. Others will need transactional charge capabilities such as a per e-mail or per help ticket opened, or the ability to fluctuate periodic recurring rates based on feature packages. Even still, some applications may need to cut “non-standard” plan agreements with certain customers to close a large sale. Even still – marketing may have the need to institute temporary discounting or model changes, while preserving the original monetization base. All of this and we’ve only discussed defining monetization – metering and billing is a whole other ball game. Metering will generally follow the complexity level defined by the monetization definitions. Obviously, if a SaaS provider is building an app from the ground up. This is where we see plenty of immediate value from the SHP concept – if this can be provided as a part of an out of box experience by a SaaS platform, an ISV can build revenue models that are very unique and specific to their needs. Nielsen’s SHP metering and billing revolves around a standardized definition language of sorts, which is exactly the way to go.

Good SaaS platforms will give the flexibility required to achieve unique and complicated monetization definitions and match that with efficient metering capabilities. Have you built or are you building a SaaS application with a very unique way to charge that you wouldn’t mind commenting about? Have you as an end user or consultant encountered any awkward yet impressively tuned usage models? I’d love to hear about them!

read more