Real World Cloud Architecture: Build or Buy a SaaS Platform?

Jan 26, 2011 by Sinclair Schuller

Yesterday, an article by Brendan Read over at TMCnet really caught my attention because it captured the spirit of what I think about every single day. The article announces the introduction of an IT service management SaaS offering by FrontRange Solutions, a relatively well known mid-market applications company with 2007 revenues at $135 million (as per their company Wikipedia entry) and apps like HEAT and GoldMine in its application portfolio. Brendan Read starts off by accurately stating that “…successfully hosting…complex applications such as IT support tools is much more than installing software onto a server and connecting it to a network that is linked to clients and their users. It requires carefully architecting the solutions for the hosted environment.” Read’s introduction set the stage for how FrontRange did SaaS the right way.

Read hit the nail on the head. Throwing an app onto some servers, whether on-premises or in the Cloud on something like Amazon’s EC2, is not SaaS. I’ve written many times about what it means to truly offer a business offering in the Cloud, but this article captures a real world example of the effort required to move to SaaS.

Read goes on to highlight data volunteered by Michael McCloskey, FrontRange’s CEO that provides an interesting data point: FrontRange “…spent two years re-architecting from scratch a new platform for the SaaS environment” Two years! (Notice the emphasis – I clearly care about this number) I don’t know the hard dollar investments made by FrontRange, but one must imagine that their SaaS platform project had a good number of developers working on it, and that the investment was, with a high probability, in the seven figure category (probably a few developers and architects, as these projects go, with a fully loaded average cost of somewhere in the $90K to $150K range per year working for two years). So a proper product to SaaS transition is a combination of 24 months of SaaS specific effort, seven figures in hard dollar costs (probably), resulting opportunity costs, and ongoing R&D maintenance costs (someone needs to fix the SaaS specific bugs and evolve the platform) – Holy smokes!

I seem surprised, but I’m really not. I’ve been in the thick of this very scenario, and responded by channeling all my effort into Apprenda. Apprenda was built on the premise that a high end SaaS architecture and operating tool-set could be productized into an application server. We built SaaSGrid to do just that – productize a world class SaaS platform so that applications running on it could inherit and give a company a sustainable short and long term solution with tremendous ROI. SaaSGrid was kicked-off as a product knowing full well the costs of a real SaaS architecture with things like multi-tenancy, provisioning, billing etc.

The scenario highlighted in this FrontRange scenario is in fact very much like the ROI analysis we go through with prospects and customers. Someone like McCloskey, faced with a SaaS decision (regardless of whether its a new application or a migration) needs to compare those build figures to investing in technology that they can buy that solves these problems out of the box. Fundamentally, you start to ask yourself:

1. Does a 12 or 24 month time to market loss result in significant competitive disadvantage? (i.e. Am I liable to lose significant market share or position by letting competitors beat me to the punch?)
2. What opportunity costs is associated with a competency distraction of this magnitude on the R&D side?
3. We haven’t built this sort of architecture before, what risk level am I willing to absorb?
4. Could an additional 12-24 month investment in the product functionality and not the SaaS platform give me access to new markets and revenue streams?
5. If a home-grown SaaS platform is going to cost $1-$3 million to materialize, what investments am I giving up to make this happen?
6. Are we going to be able to lend resources to the SaaS platform over time and evolve it despite it being orthogonal to the product, and if not, what untapped value are we leaving on the table?

If you add up the hard dollar costs of the above questions, you start to realize that millions of dollars are required, and the soft dollar costs add many more millions. SaaS is a strategic advantage, but the cost of that advantage is whats in question. Clearly, I do not think that building is a sustainable or strategic overall approach – it’s expensive and distracting. Thats not to say a company can’t be successful (just ask Salesforce.com), but the probability of success goes down while risk goes up when you build. We’ve seen this before – most companies don’t go out and build relational database servers because its not their core competency. Instead they download or license an RDBMS. A SaaS stack is of the same complexity level and same level of orthogonality, so why build? Our goal with SaaSGrid was to let people focus all of their energy on their offering – the stuff that your customers care about – and not on SaaS. My bet is that Cloud build vs buy cases like this will one day define a Harvard Business Review case study or two;-)

How do you feel about this  - does building make sense, or is the ROI not there?  Do circumstances exist where building is warranted, and if so, what are they? What other costs can you think of that should be factored in the SaaS platform build vs. buy?

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

What’s the long term cost of not using a PaaS?

Apr 3, 2009 by Sinclair Schuller

If you’re an ISV considering SaaS as a delivery model (whether it’s for a new product or migrating an existing one), you’re going to inevitably bump into SaaS platforms as a potential means of building your service. Once you do, you’re presented with two options: (1) build a fully integrated SaaS offering yourself which includes your actual offering (say, an HR solution) and the underlying SaaS mechanics (relevant SaaS delivery components like multi-tenancy, onboarding and provisioning, high availability architecture, web services API, etc.) or (2) build your actual offering (the same HR solution) atop a purpose built platform as a service (PaaS) offering that does the SaaS heavy lifting in your architecture. When faced with these two options, the astute decision maker will inevitably ask:

“Well, a PaaS seems to save us a ton of upfront effort and cost. In fact, it might cut our costs down from $600,000 and 14 months to $200,000 and 4 months. However, if we go with a PaaS, we’ll have an ever present operational expense that never goes away. If we go with option 1 and just bite the bullet, sure we’ll spend the money and time upfront, but that’s just a one-time investment. Won’t we experience ROI on that 10 months and $400,000 rather quickly?”

My answer is an emphatic no! Now, don’t take the platform guy’s (me) word for it: let me put some substance behind my claim. To understand why I say no, let’s really understand the question. Starting from the top and irrespective of the aforementioned question, an ISV is deciding to deliver software functionality to the web. That functionality is valuable to their customer base. The better the ISV is at their core competency of capturing value for their customer, the better off the customer is and the more likely the business is to succeed. If you’re building an HR app, every minute and dime your company invests in HR functionality could yield added value for your customer and higher revenue for you.  At no point does this suggest that somehow the delivery model is the core value offering to your customer, or that your competency is in constructing a delivery model. In fact, it’s a distraction to the primary goal. Now, going with option 1 with a notion that we have to “Build it here because it’s a one-time investment and we’ll make a return” assumes that it is in fact, a one-time investment. This couldn’t be farther from the truth. Realistically, you’ve in fact decided to take on the burden of whole product line and its lifespan. I’ve constructed a conceptual diagram to capture the rough notion of relative cost between your actual offering (an HR app), the “home built” SaaS delivery model stack, and opportunity cost (all of which I’ll discuss)

At the start of your SaaS journey, option 1 means that a huge chunk of your development time and money (40% – 70%) will be focused on solving SaaS delivery model problems and not on the value proposition you plan on delivering to customers. This is what accounts for the added 10 months and $400,000 in our initial scenario. Now, if the buck stopped there, our decision maker might be right: ROI is right around the corner. Realistically, you’ve made a first attempt at building a SaaS delivery model and have rolled out a very immature SaaS support stack. Once you launch your product, you’ll start your first maintenance and “new feature” phase of your offering. During this period, you’ll find that the most bugs and changes are coming from deep SaaS architecture problems and change requests. Your time will most likely be diverted away from product change requests (read: innovation) by SaaS stack repair. If you’re successful, you hit some “scale event” and feel a massive “cost pinch” and risk point. The scale problems in this case are most likely a result of poor assumptions in the SaaS stack, or the coupling of your actual application to the underlying delivery model machine. This cycle of maintenance effort and scale events will likely happen a couple of more times, and a couple of years down the road, with thousands of man hours and lots of money spent on the SaaS stack, you’ll reach a point where the stack effort starts to decrease, giving you some breathing room. At that point, you’re done battling fires with the fits and starts of big problems and maintenance phases, but opportunity cost ambiguity kicks in; are you going to exert effort on your core product or boost value in the delivery stack? Odds are you’ll forgo improving the stack (despite the massive value it can inject in your business) in favor of responding to customer demand on domain functionality need in your nifty HR app (since you’ve been distracted by the SaaS stack for so long). Those opportunity costs mount, and potential added revenue or savings opportunities disappear. Think of simple examples like giving your customers the ability to download data backups: is that an application specific problem or a “horizontal” problem for which a stack should be responsible? Do you want to waste effort on this or would it have been wiser to build on a PaaS that either has this functionality or that would introduce it faster than you would? I guess it wasn’t a one-time investment after all! In fact, it seems to be a massive ongoing investment with little predictability or bounds. This discussion hasn’t even touched on the maturity concept (for example, a “home built” SaaS stack will bump into security problems, bugs, etc. that get resolved in PaaS offerings much quicker because of the speed at which they scale due to aggregation, and the fact that PaaS providers focus solely on solving these problems).

When looking at a PaaS offering like SaaSGrid, you need to understand that paying a utility fee gives you a fully maintained delivery model without the ongoing headaches; one that will evolve much faster than you can imagine, constantly adding value to the guest applications that depend on it. If this isn’t enough, history has shown us great analogies. For example, why don’t people write application servers each and every time they write an on-premises web app? Because it doesn’t make fiscal or logical sense! You just download JBoss or buy WebSphere and go about your business! It’s very difficult to argue that a “home built” stack would be more powerful, less costly, and more able to keep up with market change.

What’s your opinion on PaaS vs. building it all yourself? Does the application server analogy resonate well with you? I’m interested in your feedback!

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

 

read more

What PaaS Isn’t: An Application with an API

Feb 13, 2009 by Sinclair Schuller

For some time, I thought I was alone in battling the cloud taxonomy war. With SaaS, PaaS, IaaS, RIA, etc. being tossed around on a regular basis, I often find myself looking for clarification when it becomes obvious that someone’s definition and understanding of one of these acronyms is different than mine and those that share a similar view as my own.

Given my relationship with SaaSGrid, the one that hits closest to home is ‘platform’ and PaaS. I bumped into a great read by JP Morgenthal that attempts to build some understanding around PaaS. Morgenthal asks whether or not simply having an API makes a web application a ‘platform.’ Does it? No. As Morgenthal points out, it seems difficult to justify Facebook as a ‘platform’ if it doesn’t act as host to application code, but simply exposes an integrations API. Unfortunately, we see folks throw platform and PaaS around all too loosely. If we think about desktop applications, it would be awkward to refer to Microsoft Word as a “word processing platform” or an “office tools platform” simply because it has an API. Some do it on occassion, but everyone is comfortable calling Word an application. Furthermore, Microsoft never made silly claims like “Write the next Word on Word” or “All desktop software will be written on the Word API”. It has it’s place in the world. However, everyone is comfortable calling .NET, or Java, or the JBoss Application Container ‘platforms’ because beyond having APIs, they act as hosts to guest software. I would say this is critical minimum criteria in claiming to be any sort of platform.

My guess is that marketing departments found that using ‘platform’ makes everything sound bigger and better. It’s not a sales management application, it’s a ‘sales management platform’. It all reminds me of a bet by the Royal Chemistry Society: they are battling the marketing folks that have used the word ‘chemical’ as negative spin in hopes of boosting the image of ‘natural, chemical free foods.’ They basically claim that the word ‘chemical’ has been misused in a very harmful way, teaching people that ‘chemicals’ are bad. In fact, all foods have ‘chemicals’ and being ‘chemical free’ is an absurd claim created by marketing departments. ‘Platform’ is a little more ambiguous than this, but the spirit is the same.

Do you agree that platform and PaaS are often misused? Does it seem to you that the word ‘application’ is falling out of favor as a proper description for standard, non-host software?

The SaaSBlogs group on LinkedIn now has 1400+ members and it’s growing every day; make sure you are not missing out and join today.

read more

Update from Microsoft PDC 2008

Oct 29, 2008 by Matt Ammerman

We’ve been here at PDC 2008 in Los Angeles all week and as many of you already know, this week has been all about delivering software as a service and cloud computing.  Ray Ozzie’s keynote really set that tone and kicked off the week. Microsoft’s Azure announcement is exciting – and it will be interesting to see how this all shakes out and the impact Microsoft’s strategy will have on the hosting industry. While we’re still here for the remainder of the week (and Sinclair is off to Rackspace to speak at their Customer Conference), we’ll be weighing in heavily when we get back.  I suspect there will be a platform taxonomy article or two coming down the pipe ;-)  Stay tuned.

read more

A Great Video Describing a Fictitious SaaS Platform

Mar 5, 2008 by Sinclair Schuller

Eugenio Pace from Microsoft’s SaaS Architecture Team published a great webcast describing the potential relationship between ISVs and hosters and how a SaaS platform fits in. It’s worth the watch. One of the major takeaways from the video is that a good platform marginalizes an ISVs efforts involving things like multi-tenancy, onboarding of new customers, monetization, operations, revenue modeling, etc. but still gives an ISV autonomy, complete control over their offerings core definition and the interactions their customers have with the application. It’s a lengthy 30 minute video, but well worth the watch.

If you watched the video, how receptive are you to the ideas Eugenio outlined?

 

read more