Understanding The Cost of Becoming a Sustained Market Leader in the Software Business through Software as a Service

Helping independent software vendors (ISVs) understand the true total cost of building, deploying and continually delivering an enterprise grade service to their customers

UNDERSTANDING THE COST OF BECOMING A SUSTAINED MARKET LEADER IN THE SOFTWARE BUSINESS THROUGH SOFTWARE AS A SERVICE
Helping independent software vendors (ISVs) understand the true total cost of building, deploying and continually delivering an enterprise grade service to their customers

Table of Contents
Whitepaper Context Abstract Introduction What it Means to be a SaaS Provider Sustained Market Leadership as a SaaS Provider Understanding Whats Important Single Instance Multi-tenancy and Juggling Competing Factors Achieving an Architecture for Sustained Market Leadership Building Single Instance Multi-tenancy Leveraging a PaaS O ering Building on Advanced Cloud Middleware Conclusion About the Author Sources 3 4 6 6 8 8 13 14 15 18 21 23 23 24

Whitepaper Context
Who is this paper for? This paper is most applicable to software companies exploring Software as a Service (SaaS) as a potential delivery paradigm, or for software companies that have settled on the SaaS paradigm and are looking to understand the tradeo s associated with di erent approaches to building a SaaS o ering and business. The paper is most applicable to the business constituents within software companies who have the ability to interpret high level discussions regarding software architectures and their impact on business metrics such as cost of goods sold, or technical audiences within a software company responsible for strategic product direction. What will you learn by reading this paper? You will learn about various SaaS business and software architectures and the cost/benet of each architecture option in both hard and soft dollar terms. You will also gain an understanding of the various solutions which can lead to achieving an optimal SaaS architecture. Can I skip sections of the paper? No. Given that the paper is a deep discussion, signicant framing is provided so that subsequent sections have appropriate context. Skipping sections might cause signicant confusion or result in a poor understanding of the overall picture. The paper does provide a full summary in the Abstract section for those interested in the primary results. Is this paper a vendor pitch? No. The paper is produced by Apprenda, a vendor in the cloud middleware space and does include signicant discussion of its agship product, SaaSGrid. However, the discussion is restricted to the end of the paper where SaaSGrid is proposed as a solution with appropriate comparison to other solutions tackling the primary problems identied by the paper. The paper spends signicant time focusing on discussing problem and solution domains. How can I measure whether Ive e ectively understood the paper? If you walk away comfortable with how SaaS architectures a ect long terms business metrics, how to best compare di erent architectural approaches in terms of short and long term costs and benets, and with an understanding of the various solutions that achieve what the paper describes as the most optimal approach to SaaS, then you most likely have a good grasp on the papers content. How much time should I expect to invest in reading this paper? 45 minutes to 1 hour. The paper covers a good number of topics in medium depth, and may require investing time in thinking through a number of the topics before moving forward to new sections.

Abstract
The software industry is clearly trending toward delivering most, if not all, business software via the Software as a Service (SaaS) model. Moving to a SaaS model introduces technical and business challenges which all Independent Software Vendors (ISVs), both new and existing must face. To date, ISVs have been accustomed to selling software licenses at nearly 100% gross margins because software is a zero marginal cost product. SaaS, however, is an operationally intensive services business where an ISV must pay for servers, bandwidth, sta , and licenses associated with o ering their service to business customers-and those costs grow with their customer base (goods sold) due to the fact that increases in the customer base require increases in capacity to meet demand (cost). The ISVs e ectiveness at keeping these costs of goods sold (COGS) as low as possible is directly linked to their SaaS o erings actual software architecture. A poor software architecture will have a poor resource utilization prole and will do a bad job at spreading costs across the customer base, while a highly e cient SaaS architecture will provide maximum resource utilization without sacricing quality. This will drive costs down and gross margins up, providing a scal foundation for achieving sustained market leadership. E ciency can vary drastically based on architecture type. Some SaaS architectures, such as single customer per server or a virtualized architecture (where the operating system and entire application stack is virtualized per customer) provide the ability to service only a single or possibly a few customers per server. Optimal architecture approaches such as single instance multi-tenancy achieve e ciencies that provide service to dozens, if not hundreds, of customers per server. To date, the trade-o has been that ine cient architectures, such as those that rely on isolation by virtualization, have low upfront hurdles from both a cost and time to market point of view, but a poor ongoing economic prole, while the investment required to build single instance multi-tenancy has been a huge barrier to most ISVs because of the specialized architectural complexity of the approach. ISVs have a number of strategies for achieving SaaS stack maturity (which requires billing systems, provisioning systems, scale-out architecture, etc.) along with a single instance multi-tenant architecture:

1. Build - An ISV can build an entire mature SaaS stack. This has been the approach for a number of SaaS vendors to date. It allows an ISV to achieve a healthy long-term nancial prole, maintain agility, and maintain exibility. However, the upfront hard dollar R&D costs, signicant slow-down in both time to market and time to revenue, and signicant competency loss creates a huge hurdle for most. 2. Platform as a Service (PaaS) PaaS providers have created runtimes or quasi runtimes in the Cloud to solve some problems associated with building cloud applications. PaaS o erings in the market span a wide spectrum of capability. On one end, PaaS o erings are too non-specic with respect to o ering a solution to SaaS architecture problems and instead are focused on infrastructure problems, o ering little value to solving SaaS architecture and commercialization problems. On the other end, other PaaS o erings are too abstract and, while solving some SaaS architecture problems, require the use of proprietary programming languages and runtimes in a limited environment that provides value only for the simplest applications. Furthermore, most PaaS o erings link the runtime with hosting operations, creating an awkward coupling that links engineering decisions to deployment decisions. As a result, PaaS requires signicant upfront investment akin to the build approach or o ers too little exibility and too much risk to be a viable option. 3. Cloud middleware SaaS application servers like SaaSGrid provide an out of the box SaaS stack that enhances traditional stacks such as Microsoft .NET with advanced SaaS architecture and tooling abilities, giving ISVs the advantages of a properly engineered build o ering with none of the negative qualities. It is the clear choice for ISVs looking for optimized time to market and time to revenue, the best possible COGS prole, with the least upfront and ongoing capital and operating investment.

The SaaS enablement market has evolved to solve a number of the problems associated with building SaaS o erings, and the market is clearly trending in the direction trail-blazed by pioneers such as Apprenda, where advanced cloud middleware allows an ISV to achieve the best possible result in becoming a SaaS vendor with the minimum possible investment.

Introduction
The past ve years have furnished a great number of proof points supporting the hypothesis that the ways software is purchased, used, and delivered are going through a permanent transformation. The notion that business end users will continue to license software and install that software in an on-premises form factor is quickly becoming pass. Recent history, through success stories like Salesforce.com, has shown that software companies can build signicant revenues as Software as a Service (SaaS) providers by giving business end users access to powerful software functionality over the Internet. Software companies e ectively become service providers by giving all customers subscription-based access to their software functionality as a service from a centrally hosted virtual location, allowing each customer to have a unique experience isolated from all other customers despite, to some degree, sharing the same system. Despite SaaS success stories, however, the software industry has not yet undergone a mass transformation. Tens of thousands of independent software vendors worldwide (easily a large majority) are still delivering their solutions to business end users as on-premises solutions. However, because of a combination of competitive pressure, opportunistic motivation, and customer demand, a signicant number of ISVs know that their evolution to SaaS providers is imminent, but have not decided how they will pursue this transformation. Strictly looking at consumption trends, it becomes quite apparent that demand for SaaS o erings continues to grow. At the time of writing, publicly available reports by Gartner show that SaaS, at least from a consumption point of view, will experience a compound annual growth rate (CAGR) of 19.4% through 2013. This growing and evolving demand creates ripe opportunity for ISVs looking to capitalize on the new delivery paradigm, and provides incentive to most all ISVs to, at a minimum, consider becoming SaaS providers, and, at a maximum, leverage SaaS as a means to become a sustained market leader.

What it Means to be a SaaS Provider

Understanding what it means to be a SaaS provider is critical in being able to fundamentally dene a path to sustained market leadership. Typically, SaaS is touted by its end users as a means of making the operational cost of running software disappear, and replacing it with a well-known usage fee for access to the software functionality as o ered by a service provider. While this statement is generally true in spirit and motivated by proper intentions, it is wholly inaccurate if looked at literally. Like any good magic trick, SaaS does not make the operational cost of running software disappear, but rather it uses a sleight of hand that transfers all the operational burdens away from each individual customer and over to the ISV en masse. Typically, each customer would be responsible for licensing the software and then hosting and managing the software so that internal end users may access it, thereby dening the total cost of ownership (TCO) of the on-premises solution. Moreover, each customer would be responsible for general e ciency with respect to internal costs; some customers would do a better job at operating their instance of the same solution than other customers, e ectively lowering total cost of ownership for the more procient customers. SaaS can create tremendous market advantage for an ISV, allowing the ISV to capitalize on new opportunities and establish steady, predictable revenue streams. SaaS is a signicant inversion of the software operating model described in the on-premises case. ISVs in the on-premises world are accustomed to near 100% gross margins when selling product since no cost is incurred by the ISV as each new customer takes on the operational burden of running their own software instance, with no impact on the ISV itself. Conversely, a SaaS ISV takes on whole and central responsibility for delivering the service to customers in exchange for revenue. Unlike an on-premises product, the SaaS ISV is not privy to 100% margins. O ering a service costs money; bandwidth, storage, compute costs, IT sta all the things each customer used to individually deal with have now become the cost to serve, or Cost of Goods Sold (COGS), that the ISV must bear (fundamentally, cost to serve makes more sense in a service business, but for purposes of familiarity, this paper will anchor on the acronym COGS).

Primary Costs are borne by the Customer in On-premises

Primary Costs are borne by the ISV in SaaS

Customer 1 On-premises installation

Operating Cost

Customer ...n On-premises installation

Operating Cost

Net Prot

Licensing Cost

In the on-premises model, since each customer was responsible for operating an instance of the ISVs software and each customer had a di erent level of competency at hosting and managing that software, there was no consistency in the total cost of operating the ISVs software. A customer with nely tuned operations might manage the software internally at a very low cost and with little to no downtime, while a customer with little experience in running on-premises software might nd itself spending large sums of money and experiencing signicant downtime. Assuming all else is equal (i.e., the same exact software architecture, an ISV hosting a physical instance of the software per customer), if an ISV becomes a SaaS provider, at a minimum they should be able to operate the software on their customers behalf at some consistent, well expected unit cost rather than have the cost of service rely on the level of expertise of each customer. Furthermore, it is most probably the case that the ISV can do a better job than almost any customer at operating their own software. The mere introduction by the ISV of consistency and ne-tuned skill around operating their own software should create some level of net savings in the SaaS to on-premises comparison, but is that enough to truly leverage SaaS, create competitive advantage, and best capitalize on the opportunity? Is the transfer of operating burdens from the customer to the ISV alone enough to qualify as a SaaS provider and remain successful? The history and failures of the Application Service Provider (ASP) model, SaaSs technical predecessor, has taught us that this is not enough. Having to worry about COGS is akin to being in the manufacturing or traditional services business, which is something an ISV is not accustomed to but needs to rapidly become familiar with and optimize if they intend to build a successful, and sustainable, business. This new protability equation sums up the true meaning of becoming a SaaS ISV; to capitalize on the SaaS opportunity or to use SaaS as a competitive advantage an ISV must give up a world of 100% margins and learn to do business with the newest line item to hit their Income Statements: COGS.

Gross Prot

On-premises -> SaaS Operating Cost Burdens Transferred from Customer to ISV

Operating Expense

COGS

Licensing Cost

Customer 1 costs ... Customer n costs

Sustained Market Leadership as a SaaS Provider

Understanding Whats Important
Dening sustained market leadership for SaaS providers is a non-trivial task, particularly when the denition of sustained market leader can be drastically di erent within any given vertical. Fundamentally, however, a few near-axioms exist. Traditionally, software companies would invest signicant amounts of money in the research and development of new software products. Upfront engineering investments for new product development were typically followed by continued investments in the evolution and maintenance of the product. However, licensing the product to customers came at little to no variable cost, essentially dening a world of 100% gross margins and a clear path to returns on upfront engineering costs. Each time an on-premises ISV sold a license to a new customer, the cost of delivering the product was virtually zero. Bits do not cost anything to replicate; a customer of an on-premises software product would most likely download the application from the Internet or receive physical media for installation. All revenues received by the ISV in exchange for the license could be applied directly to recouping an initial investment and to operating expenses since no per-unit costs needed to be accounted for as COGS. As described earlier, this is not true for a SaaS ISV. Some portion of all revenues must be allocated to paying for providing the service, and as a customer base grows, so does the total cost of delivering the service. Once this o the top expense is accounted for, the remaining can be applied toward recouping investments or paying for traditional operating expenses and some money remaining to satisfy shareholders penchant for prot. It would be fair to say that the one common scorecard that most businesses share is the ability to turn an eventual prot. At a minimum, it can be agreed that sustained market leadership in any business will undoubtedly be linked to protability. Within SaaS, this is also true. As a model, SaaS introduces sensitivity around certain key metrics: 1. COGS (as dened earlier) 2. Monthly recurring revenue (MRR) The amount of revenue that can be expected on a recurring basis 3. Customer acquisition costs (CAC) How much the company must invest in acquiring a new customer. Across a specied time period, this is the fully loaded cost of all sales & marketing expenses divided by the number of customers acquired in the time period. For example, if $100,000 is spent on sales & marketing functions over the course of the year and 10 customers are acquired, the CAC is $10,000. 4. Time to Recover CAC (TR-CAC) A measure of the number of months it takes to break even on CAC and start turning a prot. This must be calculated from gross margin that is, if it costs $10,000 to acquire a customer and you make $1,200 per month from that single account but the monthly COGS on that $1,200 is $200, you apply the di erence, or $1,000, toward the $10,000 CAC. This means your TR-CAC is 10 months.

Many other metrics could be taken into consideration, but interestingly, COGS remains one of the most important: monthly recurring revenue can only drive prot if COGS is low enough to leave cash for operating expenses. CAC is extracted from operating expenses, meaning that the rate at which CAC is recovered is wholly dependent on COGS. If COGS is too high, TR-CAC is extended. Inversely, assuming all else is equal, the lower the COGS, the shorter the TR-CAC. In SaaS, COGS is particularly important since usage fees charged by SaaS vendors tend to be razor thin when compared to their chunky on-premises license counterparts. These thin revenues create pressures to maintain healthy operating margins. It becomes quite clear that between two competing SaaS vendors, the one with a lower COGS prole has the potential to achieve protability sooner, fund new growth, recover customer acquisition costs sooner, and establish a leadership position in the market (of course, assuming that the two vendors are nearly on par with respect to all else).

In fact, COGS could almost be considered the single most important e ectiveness measure in SaaS, or, at a minimum, dene the foundational stability of sustained market leadership. A sub-optimal COGS prole means that either an ISV will lose money hand over st or raise prices to astronomical levels (relative to a cost e cient market competitor) in order to stay in business, which wreaks havoc on value perception within the market. If all this discussion of the importance of COGS is true, then the next question becomes, What denes COGS in the SaaS business and how can a SaaS provider inuence it to take the upper hand in establishing market leadership as a SaaS Provider? The costs associated with delivering a SaaS o ering can vary, but a few core costs that can be considered common among all SaaS vendors and that grow or shrink as a function of the customer base include: 1. Infrastructure costs Infrastructure requirements will grow as a function of an applications general compute and storage requirements and growth in the number of customers using the SaaS o ering. This is true regardless of whether you are using cloud infrastructure such as Amazons EC2 or physical hardware running in some datacenter. 2. Bandwidth costs Although bandwidth costs have declined drastically, their cost in o ering a service in the Cloud should not be ignored. The total bandwidth consumed on a monthly basis will increase with both an increase in per customer application usage as well as with increases in the number of customers. 3. IT Sta Regardless of whether an ISV is deploying to cloud infrastructure or a physical datacenter, IT sta is required to manage server instances and other infrastructure in support of the SaaS o ering. In most cases, as the network infrastructure footprint grows, so will the pressure of managing the infrastructure, requiring additional sta to keep pace. 4. Licenses (if applicable) Depending on what stack an ISV chooses to write their software on will determine licensing requirements for stack support software. For example, if an ISV chooses a LAMP stack, odds are that little to no cost will be incurred for running the underlying stack. However, if an ISV is building on the Microsoft platform, the ISV will have to license Windows and SQL Server, and the fees will grow proportionally with the growth of the underlying infrastructure. The overall impact of these components on COGS is highly dependent on: 1. How e ective an ISV is at distributing these costs amongst its customers and reducing incremental costs per additional customer 2. What part of the application stack the ISV is relying on for isolating one customer from another 3. How e ective the ISV is at generating e ciencies at scale Interestingly enough, an ISVs ability to properly create cost leverage across these resources is directly related to how the ISV has architected their SaaS o ering. A SaaS o erings architecture will dictate how e ectively it shares the resources described in the aforementioned list. Although thinking about COGS and its e ect on a SaaS providers protability may seem like an uncomfortable idea, it is no di erent than looking to the e ciency of a manufacturers assembly line for an indication of its production costs. The more ne grained the SaaS o ering can be at sharing resources among many customers, the lower it can drive COGS. A coarse grained sharing (such as an approach where the full application, operating system, and hardware is replicated per customer ASP model) leads to an over-allocation of resources creating low general system utilization and large amounts of idle resources which leaves signicant money on the table that could have either made it to the SaaS companys bottom line or been passed on as cost savings to the customer.

Fundamentally, one primary dimension of a SaaS o erings technical architecture is how one customer is isolated from another customer in the system. The choice of how isolation is performed and what part of an applications stack is providing isolation will directly impact the applications tenant density, or how many customers can share a common resource footprint associated with the aforementioned COGS components without sacricing general quality. For example, if a certain architecture approach provides 2:1 density ratio, it means that 2 customers can co-habit 1 server (this is a generalization that attens the idea of whether certain app tiers are more dense than others, etc. More complex measures can be taken, such as density by tier, but for the purposes of illustration, a generalized density number works best). Low density equates to a high COGS prole while high density drives a low COGS prole. Generally, SaaS architectures can be bucketed into four categories: 1. Single physical instance per tenant Each customer is assigned to a dedicated physical server, leveraging physical isolation to ensure customer isolation. Essentially, this is the ASP model. 2. Single virtual instance per tenant Each customer is assigned to a virtual OS stack running on a hypervisor that is managing some physical server, leveraging the hypervisors ability to isolate virtual machines (VMs) as a means to provide customer isolation. Technically, this is a form of ASP. 3. Tiered single instance multi-tenant Each customer is represented by meta-data within the SaaS architecture. This meta-data is used by each tier of the application (e.g., database, web service, user interface) to provide isolation and higher order resource sharing, such as many customers sharing single instances of single application components such as the database. Isolation and sharing is the responsibility of the application and cannot be deferred to the infrastructure. 4. Single instance multi-tenant Similar to tiered single instance multi-tenant with the caveat that a single logical instance exists of the application without the acknowledgement of architectural tiers.

The rst two architectures are not software architectures at all, but rather systems architectures that leverage infrastructure properties for isolation and resource sharing that is, servers are assigned to specic customers to separate one customer from another and to assign specic resources to each customer. An application can be nave with respect to isolation and resource sharing. On the contrary, single instance multi-tenancy requires that the SaaS o ering be built as extremely complex software architecture that takes over the mechanics of isolation and resource sharing explicitly.

Total Recurring COGS

Physical instance per customer Virtual instance per customer Single instance, multi-tenant

Number of Customers

Comparisons between the di erent SaaS architectures should be made on the merits of COGS e ciencies, impact on corporate operating expenses for any non-COGS costs, and opportunity costs (i.e., do some architectures introduce the possibility to posit value such as the ability to introduce features and functions into the SaaS o ering not possible, or at best, di cult to implement, under one of the other architectural paradigms?). Continuing with the theme of COGS, we can hone in on understanding why COGS is impacted by understanding tenant densities in each scenario: Approach Physical instance per tenant Tenant Density Ratio 1:1 ratio Description Each customer provisioned to the system requires human intervention to setup an actual server on which a specic installation will run for a specic customer. ASP businesses function in this manner. 1000 customers would

Physical instance per tenant

2:1 ratio to 8:1 ratio

Hypervisors slice physical infrastructure into full OS stacks, o ering virtualized isolation and replicating the entire application stack for each customer. The actual achieved tenant density depends on the minimum requirements of the application and the specications of the underlying servers. For example, if the database and frontend for an application requires 4 GB of RAM, a physical server with 24 GB of RAM could a ord to host 5-6 virtual machines, providing a 5:1 or 6:1 ratio. At a 5:1 ratio, 1000 customers would require 200 servers.

Tiered single instance multitenant or Single instance multi-tenant

10:1 ratio to hundreds:1 ratio

No explicit linkage exists between provisioning a new customer and provisioning xed network resources. Lack of clear mapping and architectural abstraction requires that the application deal with isolation mechanics, allowing for ne grained usage allocation and utilization independent of infrastructure allocation. 1000 customers would require anywhere from 100 to potentially as few as 4 or 5 servers

Some argue in favor of a virtualized approach, but at scale and in the long term, VM based models could a ect top-line e ectiveness by creating articial ceilings on gross margins and negatively impact the bottom line by adding signicantly to ongoing operating expenses and R&D investments needed to manage huge farms of single tenant, single instance deployments. Comparing these various approaches from an e ciency point of view is analogous to comparing how much roadway space is required to move 100 people either by car (single instance models both physical and VM), where each person drives their own car, or by bus (multi-tenant models), where all 100 are moved by a single bus.

(Image from the City of Mnster, Germany - Planning O ce)

The amount of roadway that a single bus requires to transport those 100 people is far less than the amount of roadway taken up by 100 cars (or by 25 cars if we transport 4 people per car to emulate a VM based compression ratio). This analogy paints a clear picture of how a specic choice of implementation (car vs. bus) impacts how nite, costly resources (roadway) are allocated and what those allocations might mean for overall costs and service levels (reduced transport e ciency, repair costs, tra c congestion, and lack of homogeneity) but also identies that complexity arises in shared environments when each passenger on the bus might want to listen to a di erent radio station on the bus without a ecting the other passengers. Clearly, these benets are realized by both the city (the SaaS vendor) and to some degree, the passengers (the SaaS customer). However, in the car/bus analogy, personalized transport by car has many advantages over the bus that cannot be addressed in the physical world. Trivially speaking, single instance single tenant architectures make this sort of personalization easy since each customer is isolated from every other by having an entire copy of the application stack, ensuring that one customers customizations do not a ect another. This level of customization is also possible in single instance multi-tenant but is much more di cult to implement and manage, requiring signicant upfront engineering e ort, creating a slightdisadvantage for single instance multi-tenant approaches. An ISV making a decision on which architectural approach is best needs to weigh the pros and cons of each.

COGS

Time to Market

Upfront R&D

Ongoing R&D

Physical instance per tenant Virtual instance per tenant Single instance multi-tenant

Legend

Optimal

Sub-optimal

Bad

Based on the discussion so far, it seems clear that single instance multi-tenant is by far the best in terms of ongoing economics, but at a signicant upfront time and money cost. Single instance per tenant architectures have very low upfront hurdles but, in many cases, o er little to no hope of good long term or at scale economics.

Single Instance Multi-tenancy and Juggling Competing Factors

Analysis provided by papers such as this one coupled with real-world SaaS success stories like Salesforce.com and NetSuite evidence the importance of single instance multi-tenant architectures. However the R&D e orts required to build this type of architecture are massive, the architectures themselves complex, and the skills required to build single instance multi-tenancy are rare2. This creates a huge upfront investment burden on those looking to become single instance multi-tenant players that signicantly impacts their time to market. In fact, pursuing the path of multi-tenancy exposes a number of competing factors that an ISV must deal with, and that in many cases, makes a commitment to this advanced and highly preferable architecture unreasonable except for the bravest ISVs. Understanding what competing factors are introduced by choosing to pursue a single instance multi-tenant architecture is critical if this architecture is to be undertaken with minimal cost and risk.

Ideal Business Outcome Competency focus

vs.

Competing Factor Loss of competency focus because of a need to build skills and competencies in complex, single instance multi-tenant architectures and engineering. require 1000 servers. Much longer time to market due to the time investment required to engineer single instance multi-tenancy into an application. Single instance multitenancy could slow a project down by 30% - 100%. Signicant increases in capital requirements due to frontloading of additional sta , tools and expertise required to build a single instance multi-tenant SaaS stack in house.

Seizing a window of opprtunity

E cient use of capital

SaaS as a whole creates a host of new R&D requirements that are critical to a SaaS companys success. These requirements range from billing systems to provisioning systems, application lifecycle management tools and more. Single instance multi-tenancy, however, is most prominent due to its pervasiveness in software architectures, the di culty of implementation, its ability to drastically swing a SaaS companys cost delivery prole, and the fact that it requires signicant upfront investment and thought. In fact, a SaaS o erings ability to achieve a low COGS prole and high level of operational agility can be boiled down to a single decision point: the build time decision of going single instance multi-tenant versus not. If this decision point is reached and single instance multi-tenancy is not pursued, it becomes very di cult to go back and correct. Clearly, given the described competing factors and ideal business outcomes, some will decide to opt-away from single instance multi-tenancy due to the upfront hurdles. Just like an electric power company might prefer to have a nuclear power plant to generate electricity cheaply in the long run but cannot stomach the upfront costs when compared to a coal red power plant, one might choose some other architecture model for SaaS because of the upfront hard and soft dollar investments required to attain single instance multi-tenancy. Given that necessity is often the mother of invention, these very pressures of being able to achieve the ultimate SaaS architecture while keeping upfront investments to a minimum have created a landscape where cloud middleware has evolved. These options allow an ISV to pursue the fruits of single instance multitenancy while keeping upfront time and money investments to a minimum. Being able to intelligently assess this landscape and measure it against the framework that has been outlined in this white paper is key to making an informed decision.

Achieving an Architecture for Sustained Market Leadership

As described in earlier sections, many scenarios indicate that the path to sustained market leadership as a SaaS provider is rooted in being able to achieve positive results in certain nancial and agility metrics, and that the probability of achieving positive outcomes for those metrics is inuenced by how the ISV builds its SaaS o ering. Regardless of the tenancy architecture, all mature SaaS o erings will share the need for a robust set of auxiliary systems. For example:

1. Subscription Management A SaaS customer typically pays for access to the SaaS o ering and in return, is a orded some level of access and metered usage that is captured in a subscription. A SaaS o ering needs to be able to dole out and assign subscriptions, use subscriptions to inuence application behavior, and provide a baseline for reconciling billing around usage. Furthermore, an engine for dening subscriptions, pricing, and feature inclusions should be in place to allow the SaaS provider to dene what subscriptions are available for purchase and to allow custom models to be developed for specic customers. 2. Metering While subscriptions dene the agreed upon terms and access rights between a tenant and the SaaS provider, metering provides a census of active usage that can be reconciled against subscriptions to properly tally a bill for the customer. 3. Billing While subscriptions coupled with active metering dene what needs to be billed to a customer, a billing engine takes over responsibilities associated with collecting money, using collection results to dictate changes to the subscription, and provide the customer with a means to participate in the reconciliation process. 4. Application lifecycle management In traditional on-premises software, an upgrade or bug x release would be sent to a customer who would then manage the process of installing the bug x or upgrade. Each customer would then perform the upgrade on their own schedule, and an upgrade mistake by one customer did not a ect any other customer. In SaaS, rolling out an upgrade or patch is much more complicated. The patch needs to be applied successfully to all customers with as little downtime as possible. Any mistakes, particularly in a single instance multi-tenant system, could cripple access for everyone. Furthermore, the complexity of an upgrade is massive given that most SaaS o erings span dozens if not hundreds of servers in a network.

5. Account Management Portals A tenant must be able to govern interactions and account information with a SaaS o ering. Exposing a portal for this is critical if the customer experience is to be thorough and comprehensive. This short list captures some major subsystems of a mature SaaS o ering. For the sake of brevity and reduced complexity, the discussion did not capture details around more di cult topics such as high availability and scale-out architecture to help ensure optimal service levels, single sign on semantics, failure detection and isolation, and a variety of other critical subsystems that are expected to be present regardless of selected tenancy model. Without even addressing the critical issue of tenancy, we can quickly see that the time and/or money investment required to build out a mature SaaS stack is huge, can easily reach six or seven gures, and can severely impact time to market. In some cases the e ort to build the SaaS stack could eclipse the e ort of the building the domain application itself. With all these architecture and delivery concerns now planted rmly on the providers plate, the application functionality that denes their value to the market has taken a developmental back seat! Although the topic of what a mature, comprehensive SaaS stack is composed of is an interesting topic, the purpose of this white paper is to examine di erent approaches to tenancy. However, the aforementioned SaaS stack components should be kept in mind for the remainder of this paper since they represent sunk costs. The solutions presented may or may not address these out of the box, and in some instances single instance multi-tenancy may itself impact the cost of buying or building these components. The remainder of this white paper will delve into a few specic approaches and conclude with an assessment of the best approach for achieving a position of sustained market leadership.

Building Single Instance Multi-tenancy

Single instance multi-tenancy is a dimension of software architecture that a ects all application tiers, auxiliary tooling, and even ongoing operations management. SaaS success stories such as Salesforce.com invested millions of dollars in early R&D to build out single instance multi-tenancy as a competitive di erentiator, relying on venture capital to ll investment gaps and achieve a vision of eventual SaaS purity. Achieving single instance multi-tenancy is non-trivial and requires a deep understanding of how the dimension impacts the application. Certain features of this sort of architecture are pervasive. For example, any code execution or data stored must be contextual, meaning that, since all application components are shared among customers, the components must be able to distinguish one customer from another and must isolate those customers from each other for safety and quality reasons. Customizations are possible where customizations are loaded on the y on these shared components based on that contextual information. An ISV pursuing a build path where they will create a single instance multi-tenant system from scratch needs to consider di erent application tiers very carefully: 1. Database/Data Storage Tier Outside of single instance multi-tenancy, data storage is relatively nave; each customer, for example, may have a specic database provisioned purely for their own data storage and processing. Although this approach is trivial to implement, it is the start of a poor COGS prole. So long as business constraints (such as legal regulation) do not prevent this, single instance multi-tenancy requires that an applications data model explicitly deal with the mixing of data from multiple customers in single database instances. Typically, this is managed through row level ownership, where specic pieces of data are tagged with information identifying which customer the data belongs to. At rst glance, this seems trivial, but be warned! The simple introduction of row level ownership means that all aspects of the data model need to be changed and managed di erently. Key structures, indexing, and access all need to change. Execution against the database needs to be managed so that, to the extent possible, queries executed by the application on the behalf of one customer do not a ect the experience of other customers. Furthermore, managing growth is complex. As the database grows, the data model should support partitioning so that some subset of the tenants can be moved to other server infrastructure to support a scale-out model but the calling application code need not know of the scale-out intricacies. Change management is much more complex since changes to the data model need to remain tenant aware. This discussion is simply scratching the surface of the complexities of multi-tenancy at the data level.

A single instance multi-tenant data model o ers the ultimate in e ciency, but if quality and exibility are to remain intact, signicant investment must be made in executing this nuanced and intricate arena of database design correctly. 2. Application Tier In a single instance multi-tenant model the application tier is being shared by many customers. Any calls to the application tier must carry and maintain information about the originating customer request if isolation guarantees are to be made with respect to code execution at that tier, and to ensure that isolation is propagated to lower tiers (such as the database or owing contextual information to other systems). In memory, requests from di erent originating tenants need to be protected from one another so no single tenants execution bleeds into another (imagine if a request for one tenant returns that tenants result to another tenant!) In more complex cases, the application tier should be capable of safely executing logic and database queries in a tenant-agnostic fashion to perform operations across all tenants or tenant data. Furthermore, if the application tier is a physical web service, expect to build a tenant level load distributor to help with scale-out and peculiar isolation needs. 3. User Interface Tier Front end user interfaces need to be capable of distinguishing originating tenants. Techniques such as providing unique URLs per tenant for identication purposes, cookie management systems, and contextual owing of tenant data on web requests are used. Furthermore, tenant level load balancing is used to distribute front end load across a server farm based on identity. If Rich Internet Application (RIA) technologies are being used, which, by default, are client side single instance single tenant systems, then those user interfaces need to maintain tenant a nity but reconcile the single tenancy with the multi-tenant back end services supporting it. In addition, modern user interfaces take on a variety of forms from browser-based to mobile, and applications should be architected to make introduction of a new client form factor easy and quick.

Aside from the application tiers just described, the non-architectural sub-systems such as billing and subscription management mentioned earlier in this section may also be impacted by single instance multi-tenancy. Some of these systems may need to follow the same architectural style or be explicitly aware of them, reinforcing the overall mantra of being single instance multi-tenant. Taking a build approach will require signicant upfront investment in hard dollar terms, soft dollar terms, and temporal terms. Furthermore, maintenance of these complex moving parts means signicant ongoing R&D investments; it is almost certain that the baked in single instance multi-tenancy and requisite support components will be the most complex, error prone parts of the system. Even in the scenario where some of these components are provided by third parties, you can expect to pay signicant sums of money over time for relatively little strategic return. Some SaaS subscription and billing systems alone can cost up to a recurring 2% of revenue for what amounts to very little overall strategic value.3 When all of this is taken into consideration, the overall prole for build is clear:

Build Single Instance Multi-tenancy

COGS

Time to Market

Upfront R&D $ Investmet

Ongoing R&D $ Investment

Competency Focus

General Flexibility

Risk

Legend

Optimal

Sub-optimal

Bad

1. COGS Clearly, a team of skilled software engineers will be able to achieve single instance multi-tenancy so a build, assuming all goes well, should be able to yield an optimal COGS prole. 2. Time to Market Build means that upfront R&D will be slowed down drastically, either signicantly delaying market release of a SaaS o ering or even creating a missed window of opportunity. A mature SaaS stack could easily become the most burdensome and slowest part of upfront R&D. 3. Upfront R&D $ Investment Most ISVs do not have skills on sta with expertise in SaaS delivery architectures and tools development. This typically means that money needs to be invested in hiring new talent, helping the current team acquire new skills, or outsourcing parts of development. 4. Ongoing R&D $ Investment Once a single instance multi-tenant SaaS architecture is built into a SaaS o ering, the ISV now owns the bugs and evolution of that signicant part of the overall application stack. Typically, sta levels will be kept high since both the main product and underlying SaaS stack must be maintained, which guarantees an inated ongoing R&D budget. 5. Competency Focus Most ISVs have high levels of competency in engineering solutions within their business domain: HR software companies write amazing solutions to HR problems, medical software companies know the ins and outs of their vertical and create solutions for that. Building a SaaS stack is a huge distraction from core competency. Imagine that relational databases did not exist and an HR software company decided that it needed to both create and maintain code for a complex relational database, and then build the HR software against that in-house database. Clearly, this would be viewed as a signicant distraction and as a result, most ISVs leverage third party database technology. A SaaS stack is no di erent. 6. General Flexibility Given that a build scenario allows an ISV to choose the stack of their choice with little to no restrictions within that stack, an ISV is limited only by its own creativity, thereby allowing it to maintain enough exibility to create feature rich applications that meet their markets needs. 7. Risk Although build is generally void of lock-in beyond traditional platform selection, the lack of expertise in building single instance multi-tenant SaaS and auxiliary tooling introduces some level of risk since the architecture could turn out to be buggy, mal-performing, or too di cult to maintain.

Pursuing build means that it is possible to achieve the best COGS prole (assuming that the ISVs engineering team has the skill set to properly execute the R&D) and maintain the power and exibility of using an industry accepted hardened stack (e.g., Microsoft .NET, Java, LAMP), but at a severe nancial, temporal, and focus penalty. The ideal scenario would be to achieve the COGS and exibility prole of a single instance multitenant model with none of the upfront or ongoing impact. One of the other architecture approaches described later will propose a solution that allows for achieving the results of the build approach, without the requisite costs.

Leveraging a PaaS O ering

An important member of the Cloud ecosystem is the Platform as a Service (PaaS). PaaS is a service that bundles a hosting infrastructure/computing platform (think servers) with a tightly coupled software stack that manages some level of burdens related to the engineering and execution of code assets. PaaS o erings span a relatively broad spectrum of comprehensiveness; some PaaS o erings provide a rapid application development stack for simplistic applications that use drag and drop widgets and scripting engines to compose functionality, while others like Google AppEngine and Microsoft Azure o er industry hardened runtimes such as Java and .NET in the Cloud. In either case, these PaaS o erings require a full stack commitment; PaaS, in many, but not all cases, marries the stack benets with the underlying hosting infrastructure and introduces some level of lock-in through the use of either libraries or custom programming languages that can only work on that specic PaaS. To provide an analogy, building on some PaaS o erings would be similar to writing an application for a yet to be adopted operating system that is tightly integrated with some specic brand of CPU, rather than writing for an operating system that is independent of the underlying CPU architecture. Single instance multi-tenancy availability on PaaS o erings varies wildly and the benet to cost ratios on PaaS o erings are mediocre at best. PaaS o erings seem to be in one of two orientations: 1. O er an industry hardened, robust runtime such as .NET or Java in the Cloud but without single instance multi-tenancy 2. O er a simplistic Rapid Application Development (RAD) environment for building simplistic database scraping applications and receive single instance multi-tenancy. For those PaaS stacks that do o er a robust runtime in the Cloud (take Microsoft Azure, for example), one enjoys the ability to deploy relatively arbitrary code to the Cloud and have innitely scalable resources at their disposal, which solves a wealth of infrastructure and operations problems. However, these benets come with the caveat that none of the architecture and engineering problems surfaced by the SaaS delivery paradigm are solved. These PaaS stacks do not o er any form of tenancy capabilities or architecture advantages to the applications they host. Microsoft Azure and Googles AppEngine, for example, are themselves multi-tenant, but do not endow the applications that run on them with single instance multi-tenancy. Furthermore, these traditional runtimes in the Cloud do not o er any of the application building blocks or management tools required to deliver a SaaS o ering, such as billing and application subscription management. Given that this avor of PaaS does not provide much with respect to SaaS architectures, a majority of the burden found in the pure build scenario for single instance multi-tenancy is still present when leveraging todays available PaaS o erings:

PaaS (Traditional Stack)

COGS

Time to Market

Upfront R&D $ Investmet

Ongoing R&D $ Investment

Competency Focus

General Flexibility

Risk

Legend

Optimal

Sub-optimal

Bad

1. COGS Since a PaaS exposing a traditional stack in the Cloud has few restrictions with respect to achievable results, it is perfectly reasonable to achieve pure single instance multi-tenancy and achieving a top notch COGS prole. 2. Time to Market Most if not all build burdens (aside from some high availability and scale mechanics) are equal to non-PaaS build which still drastically impacts up front time investment and project drag. 3. Upfront R&D $ Investment Some complexities around scaling and availability architectures along with easily provisionable resources eases some of the skill-set requirements when building single instance multi-tenancy, which may reduce hiring pressures and pressures on capital. 4. Ongoing R&D $ Investment The same ongoing investment rationale of a non-PaaS build still applies. 5. Competency Focus The same lack of focus on core competency described in non-PaaS builds still applies due to the fact the all the SaaS-specic components of the platform (multi-tenancy, user systems, billing, etc) still need to be created by the ISV and baked into their application. 6. General Flexibility Given that few restrictions exist in traditional stack PaaS o erings, ISVs still have full exibility to build out complex feature sets and maintain complete control of the SaaS o erings direction. 7. Risk The non-PaaS build scenario described the risk of incorrectly building and maintaining a single instance multi-tenant SaaS stack, which still applies in this particular PaaS form factor. New risk is introduced on top of the already described risk, however. Given that most traditional stack PaaS o erings have coupled the stack runtimes with the underlying hosting infrastructure, freedom of choice with respect to hosting is lost. This means that although both the engineering and hosting value propositions of a PaaS might be appealing at rst, if the hosting quality degrades, the SaaS o ering cannot be moved and hosted someplace else. This coupling introduces a dangerous new form of lock-in risk. Some of the other PaaS stacks, such as WaveMaker, LongJump and Salesforces Force.com o er some semblance of single instance multi-tenancy but through signicant layers of abstraction or atop brand new runtimes with custom programming languages and shallow functional sets. Typically, these PaaS o erings o er Rapid Application Development (RAD) environments and/or visual application builders to optimize programmer productivity, but at the expense of nearly everything else. Clearly, these tools might provide amazing value to business users looking to rapidly build simple applications; but considering the complexity of most ISV applications, they tend to be far too simplistic to support multi-million dollar SaaS o erings. A RAD PaaS approach requires that an ISV abandon skill-sets, existing investments, and existing engineering assets and migrate entirely to these new PaaS o erings while sacricing signicant exibility. Although some aspects of SaaS delivery architectures are baked into these PaaS o erings, they come at a signicant cost.

PaaS (RAD)

COGS

Time to Market

Upfront R&D $ Investmet

Ongoing R&D $ Investment

Competency Focus

General Flexibility

Risk

Legend

Optimal

Sub-optimal

Bad

1. COGS A number of RAD PaaS o erings abstractly capture single instance multi-tenancy so that the applications built on them can inherit that architecture. This guarantees that resource sharing is happening to some degree, but two factors reduce the value to sub-optimal levels. First, these systems, because of new runtimes and abstractions, typically cater to a least common denominator model by creating signicant meta-data overhead which will reduce overall e ciency. Second, from a pricing point of view, a number of RAD PaaS providers charge by % of revenue or xed fee per some unit (such as per end user), creating an articial oor to unit cost. This means that even if an ISV has a means to improve utilization within the application, pursuing the optimization would not be worthwhile given that it could never escape the PaaS vendors cost structure. 2. Time to Market RAD PaaS o erings typically are highly tuned for maximum productivity within the set of problems which can be solved using a PaaS, so generally speaking, they o er a signicant time to market advantage. 3. Upfront R&D $ Investment Although most RAD PaaS o erings claim signicant reduction in R&D investment, this tends to be true only in some cases, but denitely not in the case of ISVs. ISVs typically need to ramp up around new programming languages and tools, come up with workarounds for limitations in these systems (since the stacks arent terribly expressive, complex application functionality must be hoisted out of these systems into traditional stacks), and calculate the costs of not being able to leverage existing assets or third party libraries,tools and modules that were usable in traditional stacks. 4. Ongoing R&D $ Investment Other than becoming well versed in the new languages, the same properties that balloon upfront investments will continue to be present in ongoing investments. However, it should be noted that if an ecosystem of third party systems around the RAD PaaS matures to the level of modern industry hardened stacks, then this cost may go down. 5. Competency Focus Competency focus should be a bit more biased toward the core given that the RAD PaaS is fundamentally built to generate some level of focus (and at this point, it wouldnt be fair to penalize competency focus analysis for learning new languages and runtimes, which were already captured in the investment analysis) 6. General Flexibility RAD PaaS o erings are typically good at solving very specic problem domains. Force.com, for example, provides a wealth of functionality and room for creativity around extending the Salesforce.com CRM system. However, deviating from this core is generally not possible or costly. For example, if an ISV is in the 3D CAD rendering space, it is quite probable that the RAD PaaS cannot provide an adequate foundation for a SaaS-delivered rendering system. 7. Risk Risk in RAD PaaS tends to be very high. Asset lock-in is a huge concern since the applications most likely cannot run outside of the PaaS container. This is an amplied concern since that means that business continuity issues, which are typically expressed as problems with respect to abandoned products, are now operational concerns since the existence of the PaaS vendor is required just to ensure that an ISVs application can continue to be o ered. Furthermore, since these RAD PaaS stacks are not yet pervasive, the ability to easily nd engineers in the workforce to fuel growth is much more di cult.

Clearly, within some subset of problems and solution needs, RAD PaaS makes sense and can o er individuals immense value. Business users needing to rapidly build situational applications, for example, may nd PaaS benecial. More often than not, however, RAD PaaS is not a solution for ISVs with millions of dollars of revenue and signicant application complexity.

Building on Advanced Cloud Middleware

The evolution of SaaS enablement started with roots in building SaaS applications in their entirety from the ground up. The huge expense, loss of focus, and ongoing maintenance burden created a market for enablement vendors to help provide solutions that would reduce the build burden. Soon after, auxiliary SaaS functions such as billing and subscription management were captured as third party tools and solutions that aspiring SaaS vendors could utilize, but no enablement technology existed that solved deeper architecture problems such as multi-tenancy, scale-out, and provisioning. PaaS vendors attempted to capture some of this complexity in a formal stack layer, but are either too low on the stack to provide meaningful SaaS architecture value, lack operational tools, or require abandoning existing programming languages and runtimes to use new, unproven stack components. They generally require full silo lock-in as well; meaning that the programming environment, language and tooling is married to the underlying hosting. As most solutions go, each generation of PaaS has provided more value than the previous. The direction of the industry has clearly been moving toward a stack approach where SaaS applications get built atop layers that aim toward providing abstract solutions to fundamental problems. The software industry is no stranger to this. The operating system provided an abstraction from the underlying hardware that catalyzed desktop development. Application servers such as JBoss in the Java world and IIS in the Microsoft .NET world removed the need for application developers to explicitly deal with HTTP conversations between the server and a clients browser (along with a host of other issues) so that web application developers could focus on meaningful code. Likewise, the SaaS application developer now has access to cloud middleware (or the SaaS application server, to continue the analogy). Cloud middleware vendor Apprenda pioneered the concept of the SaaS application server with the introduction of SaaSGrid. SaaSGrid is a server technology which fundamentally solves the most critical problems in building and delivering SaaS applications (including complex issues such as single instance multi-tenancy) with very little sacrice. Cloud middleware captures a SaaS stack as a server layer, allowing applications built on top of it using traditional stacks to inherit a pure SaaS architecture with little risk or lock-in and removing nearly all the build burden. Much like an application built on Windows does not need to understand the intricacies of how Windows communicates with a hard drive to be able to store data on disk, applications on technologies like SaaSGrid simply enjoy an enterprise grade SaaS architecture vicariously. To provide context for the analysis, understanding SaaSGrid both conceptually and physically is important. SaaSGrid is a SaaS application server that stitches together any number of Windows based servers into a single, distributed logical software layer and enhances the existing Microsoft platform to be nely tuned for advanced SaaS delivery. Software engineers write traditional, single tenant web applications using standard Microsoft platform technologies such as .NET, SQL Server, and ASP.NET. Application components are provided to an individual SaaSGrid instance using SaaSGrids management portals and deployed on-top of the SaaSGrid runtime. SaaSGrid transforms various parts of the application and instruments the applications with advanced architecture capabilities, while also linking the application to a number of management and commercialization consoles. SaaSGrid introduces single instance multi-tenancy into the application architecture automatically and transparently. Rather than relying on nave coarse grained OS virtualization, which forces a full replication of the application stack per customer, SaaSGrid injects architecture virtualization into the application components themselves. The database, for example, is itself virtualized as a stack component, meaning that what was a single tenant data model becomes capable of storing data for multiple customers in single, highly scalable database instances, but in a fashion that is transparent to the calling application (remember how our Windows application didnt need to know about how Windows I/O works against a hard drive). Although seemingly magical, SaaSGrid relies on advanced architecture capabilities to introduce the single instance multi-tenancy dimension to all application tiers without risky requirements such as new languages or runtimes. Additionally, SaaSGrid provides the remainder of a pure SaaS stack, including all the components described earlier in this section such as product management tools, billing capabilities, grid based load distribution, failover, failure isolation, and a number of other operating features. SaaSGrid is a pure middleware layer with no awkward coupling to a hosting environment. SaaSGrid can be deployed anywhere that Windows server is available, whether it be a Cloud provider such as Amazons EC2 or traditional hosting provider such as Rackspace or PEER1.

Cloud Middleware such as SaaSGrid is optimized for a best of breed prole that reduces upfront costs and time, as well as ongoing operational costs. SaaSGrids e orts are focused on purely solving SaaS architecture and tooling problems rather than being a vague solution (traditional OS virtualization) or too egregious and unnecessarily binding (most PaaS o erings). Hosting and infrastructure solutions are left to the best of breed providers in that category, with cloud middleware solving the complexities of SaaS, leaving the ISV with a wholly optimized stack and the ability to focus on writing software that is important to their customer base. The end result is a cost benet that makes sense: SaaSGrid

COGS

Time to Market

Upfront R&D $ Investmet

Ongoing R&D $ Investment

Competency Focus

General Flexibility

Risk

Legend

Optimal

Sub-optimal

Bad

1. COGS Cloud middleware like SaaSGrid leverages advanced intellectual property to merge its abstract single instance multi-tenant stack and tools (automatic provisioning, etc.) into a guest applications architecture. By keeping a strict separation of concerns, technologies like SaaSGrid optimize for the most e cient single instance multi-tenant model while software engineers can optimize the performance of their application code. This focused optimization allows cloud middleware based applications to achieve minimum COGS through maximum tenant density. 2. Time to Market SaaSGrid allows for rapid application development by removing nearly all SaaS specic e ort. An ISVs time to market becomes purely dened by the project scope of the application itself, and not the project scope coupled with the SaaS stack scope. This yields a most optimal time to market, and in cases where the cloud middleware provides commercialization tools to dene pricing schemes and publish self-provisioning storefronts (as SaaSGrid does), time to revenue is also signicantly optimized. 3. Upfront R&D $ Investment Cloud middleware is typically sold as a product and is licensed to ISVs. The cost associated with the licensing must be viewed in relative terms; when compared to build costs, the licensing tends to be signicantly lower (for example, cloud middleware, in most cases, could reduce project costs by 30% to 60%, amounting to hundreds of thousands, if not millions, of dollars) but is not a zero cost endeavor (like pure application replication through virtualization might o er). Furthermore, although extremely low, initial costs associated with familiarizing a team and project with middleware must be factored in. 4. Ongoing R&D $ Investment Ongoing R&D costs are optimized to be as low as possible. Knowledge acquisition surrounding the middleware is absorbed at the beginning of the project, and ongoing education tends to be minimal and easily absorbed. Due to forcing separation of concerns, ongoing R&D investment from the ISVs point of view is solely focused on evolving the application that their customers pay for while maintenance and evolution of the SaaS stack is the responsibility of the cloud middleware vendor. 5. Competency Focus SaaSGrid allows for high levels of focus on core domain competency and core skill-sets. Some focus is directed toward understanding cloud middleware early on, but this one time investment is amortized across the subsequent high levels of focus directed away from the SaaS stack. Reduced distraction allows for the necessary agility to gain sustained market leadership.

6. General Flexibility Properly built cloud middleware is built with the understanding that existing platform technologies are unbelievably expressive and capable, giving software engineers and architects the right tools to solve problems of ever growing complexity. By focusing on extending the capabilities of existing stacks, cloud middleware like SaaSGrid allows one to pursue advanced SaaS delivery architectures without sacricing the ability to use industry hardened stacks like .NET and leverage the massive ecosystems that have been built around these technologies over the years. 7. Risk Technologies such as SaaSGrid can overcome short term risk by being able to evidence the qualities of an advanced SaaS architecture out of the box, unlike a build approach which might take months just to produce a fragile prototype. Furthermore, by leveraging existing stacks, not requiring new skills, and allowing freedom of choice when it comes to deploying an application running on SaaSGrid, lock-in risk is extremely low.

Cloud middleware such as SaaSGrid provides a backdrop for advancement where the middleware provider can continue to drive innovation with respect to the SaaS stack and vicariously introduce refreshed benets to the ISV over time, while the ISV can optimize business metrics and development e orts around strategic goals associated with servicing their customers.

Conclusion
This whitepaper clearly identies the impact of the various SaaS architecture approaches and reaches a clear conclusion that for long term, sustained market leadership a SaaS provider should give serious consideration to single instance multi-tenancy at some or all of its application tiers. Single instance multi-tenancy and eventual full SaaS stack maturity can be achieved through a number of approaches ranging from expensive build approaches to using advanced middleware. When looking at build, PaaS, and virtualization, each provides certain uniquely positive qualities, but always at the expense of some other quality. The future of the Cloud will be fueled by technologies like SaaSGrid that have been optimized to provide the best qualities in SaaS architectures while neutralizing or even optimizing qualities that typically acted as counter-balances in competing approaches. ISVs can benet from the best possible cost and risk prole without sacricing strategic direction or introducing tactical friction.

About the Author

Apprenda is the creator of SaaSGrid, the industrys leading Application Server for superior Software as a Service delivery. SaaSGrid solves both the upfront and ongoing technical and business challenges of delivering software as a service, by providing software companies with zero-e ort single instance multi-tenancy and grid scalability in addition to out of the box application services like metering and monetization, billing and subscriber management, and much more. To learn how SaaSGrid can help you get to market faster and save you thousands of man hours of operational overhead visit http://www.apprenda.com or contact us at: Phone: (877) SAAS-WEB Email: info@apprenda.com

Sources
What if Salesforce.com Werent Multi-tenant?: http://www.saasblogs.com/2009/05/05/what-if-salesforcecom-werent-multi-tenant Zuora Aims To Be Salesforce for Online Billing; Benio Agrees: http://techcrunch.com/2008/05/20/zuora-the-salesforce-for-online-billing-launches SaaS is a journey, walk with us: http://blogs.msdn.com/fred_chong/archive/2006/02/17/534633.aspx