“Scalability” is one of many cloud buzzwords that is fraught with confusion. Most of the time the term is used with a mixed meaning – covering both technical scalability provided by implementations of infrastructure virtualization and business model scalability. The problem is technical scalability by itself cannot impart scalability to a business model. But, on the other hand, technical scalability can be a crucial component of a successful and scalable cloud business model.

In this two part series, we will address the key technical capabilities required in a cloud service to achieve a scalable business model. I’m writing this article because we have found the confusion to be a common thread throughout many interviews and consulting sessions with software vendors bringing their products to the Internet as services. Almost without exception, vendors address end-user functionality clearly, but fail to address their own need to have a successful, repeatable and scalable business model.

A business model is said to be scalable when the incremental cost of acquiring, implementing, servicing and supporting a client drops as the number of clients increases. In a few business models, the service is repeatable but total costs remain relatively stable as the growth curve rises.  In these cases, incremental profit needs to flow from each new client regardless and attractive scalability will be hard to achieve. A fully-scalable business model is not constrained by resources such as skilled staff or materials. Full scalability is not achievable in all markets or business models. In all business models, the total incremental cost per client will eventually reach a point where it is zero or flat.

When the software industry was primarily selling licensed software – scalability was easy. ISVs would develop a software version once and sell it as many times as possible before investing in another version. Each incremental sale from a version lowered the total cost of goods for the ISV. ISV’s selling licensed software only noticed a constraint when the cost of support to each incremental client was more than the client’s share of the cost of goods generated by application development.

In a cloud service model, the challenge is to identify the services and features you must provide and then implement them so that the incremental cost of providing services for each client goes down as the number of clients grows. To accomplish this, the application has to be planned to support a scalable business model from the beginning. Otherwise the cost, risk and disruption from later changes will itself constrain scalability and cause costs to be higher rather until the investment is offset by profit.

The other challenge is that even a bad business model can look scalable during initial marketing ramp-up and growth.  Rapid growth can temporarily obscure the reality that the costs of implementation, support and operations required are not actually going down as the client base grows. Eventually though, as the growth curve begins to flatten and constraints appear, the pressure to maintain cash flow will make it apparent that the business model cannot be sustained long enough to reach an attractive profit.  In services where the amount of skilled staff required to implement each client is remains constant regardless of the number of client served, the cost and time required to acquire and maintain skilled staff will eventually become a brake on growth.

The length of the curve from the point where a business model begins operation to the point where it reaches a zero incremental cost per client, a flat level of cost per client, or a constrained-level of costs per client is the business model’s scalable range. As cloud service providers, the goal is plan the service so you are able to bring incremental costs per client to the far-end of the scalable range – to the point where the incremental costs per client are the most optimized.

The following points are aspects of the application and technical implementation that can provide leverage for business model scalability. They do not have to be achieved on day one of offering a new SaaS product or cloud service. However, to have a successful and scalable service from a business point of view, the application, its architecture and the infrastructure that supports it must be capable of achieving these points within a reasonable period of time without an application rewrite or major reconfiguration of the service.

Checklist for Business Scalability in the Cloud

1. Application architecture is component-based, uses web-services and the database is multi-tenant. In today’s development environment for cloud services, component-based architecture and web-services should be a given. These approaches provide much of the flexibility and continuous improvement we take for granted in online applications today. And without getting into a lot of religious battles about multi-tenancy – the point here is business model scalability. If you do not use the most scalable database architecture, you will always carry the risk and skills necessary to scale and manage alternative approaches.
2. Application maintenance and updates can be applied, or rolled back, to all client instances without business interruption and with minimal effort. In today’s market, cloud services are expected to have both continuous updates and operation. The procedures required to maintain application availability during updates need to be integrated into application development, straight-forward and repeatable.  Again, this has become an expectation across the industry. If your service has significant “down-time,” either planned or unplanned, your availability and reliability will be suspect from a client point of view.
3. Operational service functions (e.g., subscription management, billing, etc.) and reporting are part of the application but separated from client functionality so that they can be extended to additional applications over time, they can be tracked and managed. Operational functions generally scale in a linear fashion as the client base grows. If they are planned properly, they can be leveraged over multiple applications during the service lifecycle – driving down the operational cost. Not having operational functions integrated and automated as part of the application means manual processes will add to the cost of each client, payment cycle, billing change, etc. Manual operations will seriously constrain scalability and profit.. These functions facilitate client interactions with the service provider but they do not directly add to the value a client receives from the service. That doesn’t mean however they are unimportant. If these functions are not automated as part of the service they become a brake on growth as service operations struggles to keep ahead of growth while keeping costs to a minimum.
4. Application services can be purchased and embedded in the offerings of other services. Planning cloud services to allow other vendors to leverage application functionality creates additional channels at very low cost and greatly improves business model scalability. It is less important to know when or how it might happen that other vendors will want to leverage a service than it is to have the capability. When it does happen, it should require nothing more than a sales negotiation.
5. Outside services can be used to extend operational or client functionality as necessary. Application development is a part of the total cost of a cloud service. Just as it is important to allow other vendors to leverage service functionality in their offerings, it is equally important to have the option of leveraging other services so you can adapt their functions into the service without “redeveloping the wheel” unnecessarily. In early phases of the product lifecycle, software development will be the largest contribution to cost and will be carried as a burden over many clients before the business can reach positive cash flow. Leveraging outside services for selected functions (like pricing and billing for instance…) can lower the initial cost of development, significantly improve functionality for non-core needs and allow development effort to be focused on areas that have higher value for clients.
6. User interfaces can be extended to alternative platforms through web services and API calls to allow users to access to client functionality on emerging devices. The market for smart phones, tablets and mobile devices is exploding but it is also highly fragmented. Tying a service to a single end-user platform can constrain growth and put the application in a lockstep with the lifecycle and fortunes of the selected platform. Providing standard, documented methods to extend the service to end-user devices as they develop greatly increases the market and lowers the risk that extensive rewrites will be needed to adapt to new technology.
7. Client implementation is automated and immediate, on demand. Manual processes and delays required for operational functions like client implementations are costs and risks. Client implementations should not require anything more than authorization from the billing and settlement component of an application. This is a good example of the “consumerization” of software. The increasing use of online applications by consumers has created expectations for user-experience that now have moved to business software and services have to adapt to current client expectations.
8. Client instance configuration and integration is client-driven. One-off customizations and integrations should be strongly avoided in favor of embedded configuration choices and API calls that provide necessary data integration. Developing and maintaining split versions is simply too risky and expensive to be considered a sustainable business practice for SaaS and cloud services.  I’ve sat with many prospective vendors who say “our users demand customization” and they simply cannot imagine any other course. But the reality is the practice only works when clients are willing to deal with the costs of system integrators, delayed version updates, and the maintenance issues the practice brings in their own data center. When clients outsource to a service they expect you to bear the cost and risks. Standardizing a product to one version, including those configurations that take the place of 80% of the individual issues clients want to address, solves a great deal of problems for both the client and the service while it increases overall business scalability.

Is this all? Not by a long shot. We’ve got 12 more points in in the second half of this article. Business scalability is a core competitive edge in SaaS and Cloud Services – so please – join us for Part 2.

This is the fourth article in a series with excerpts from this year’s workshop titled, “How to Eat an Elephant – Developing a Real-World Product SaaS Product Roadmap.” Each of these articles will cover one part of core subjects in our Cloud Product Roadmap.  If you are just joining us – you can return to the first article in the series and find out more about the workshop background and other articles in the series.

Excerpt: How to Eat an Elephant Workshop by Scio Consulting

Planning and developing a Cloud product can be a daunting prospect, especially if using cloud-based infrastructure and services requires a departure from your “comfort zone” in more traditional installed and server-based products. One of the biggest concerns is developing the architecture for the project. For an implementation on something like Amazon Web Services how do you decide on the break-down of the application between the various services Amazon provides? Can you model the utilization scenarios and understand your costs in different situations?

Before you begin that consideration – let’s first make it clear that straightforward server virtualization is not the key feature of Cloud technology. Where Cloud implementations really shine in their value is in the ability to provide highly elastic capacity for specific application elements. This means the architecture can to break out client service elements that are based on utilizing elastic storage, moving large amounts of content, or have bursty characteristics.  Simple server virtualization schemes are limited reaching these scenarios economically because they are based on replicating a the server footprint rather than extending individual application  components.

On the other side of the coin, the “client side” of the application is not the only thing we’re concerned about. We also need to consider an operational side of the application that will support our product strategy and business model.  Hobbling operations by relying on manual processes to onboard customers and handle operations is not a sustainable way of dealing with the “back office details” of the service.  Generally, the operational side of an application will scale in a linear fashion. These components will scale in relation to the number of clients rather the usage patterns of application features by clients. That means utilizing different scaling strategies for various parts of the application. It also means cost modeling needs to be split between dynamic services that are consumed directly by client use and the more linear use patterns of components that are required to operate the service.

To understand the issues, let’s go back to one of the basic problems of a SaaS or Cloud product. There are several elements of these applications that are critical to operations but take considerable effort to plan, develop and implement:

• Multi-Tenancy – For most SaaS and Cloud Services, multi-tenancy is the core approach to application management, generating new instances, and structuring client data. Multi-tenancy is implemented in the database of the application itself.
• Application Management and Availability – Regardless of whether they are designed for the Cloud or not, modern applications are not monolithic. As we have discussed, they are actually a group of components that may have different use patterns and performance characteristics. Managing performance and scaling for the entire application is a basic requirement, but in a component model, you may need to manage performance and response at the component level to leverage the opportunities that true Cloud architecture offers.
• Product Management – Configuration, metering and billing are necessary to manage service packages that can be offered to clients. It is likely your packages will change over time, so your management system needs to be flexible and accept a wide range of scenarios. If you plan to leverage reporting to determine feature acceptance and value, you also need to be able to monitor feature-level usage over time.
• Usage Metering & Billing – If your service has usage-based billing, no matter how it works, you need some way to translate usage into billing. What seems simple can be come complicated quickly when you are faced with various combinations of partial months, changing user counts, differential pricing by user role, promotions, and other unexpected complications. Being able to respond to a changing elastic deployment. It requires much more effort to maintain reliability over changes to the core and operational sides of the application. In the best case, the basic architecture of the application platform supports the kind of load-balancing and instance version control that makes this possible.
• Subscription Management – A subscription is the package of services that a client has subscribed to and pays for in regular periods.  Although they are utility-based, very few Cloud Services can adopt a totally unpackaged, spot use model.  Granular spot use models are hard for the client to plan for because they can represent a risky “uncapped expense.”  And – unless they are based in regular use by a very large client base, they can result in a cash flow that is impossible to plan on. Because of this, regardless of how the service works, most SaaS and Cloud Services will have subscription-based packages and require on-going subscription management and the ability for clients to change subscriptions based on the current feature pricing schema.
• Access Control – Users must be able to access the features related to their role within their company subscription and if the service includes a suite of applications – their access needs to reflect their participation in the suite.
• Customer On-Boarding and Provisioning – When a customer signs up and is accepted, the application should be able to use the information provided at signup to provision a client instance and provide the necessary credentials, roles and access needed to the customer without any manual intervention or coding.
• Service Management and Configuration – When web services are used to provide the different components of an application, each service needs to be managed, versions need to be tracked and dependancies need to be respected. Without a management tool, this work needs to be done manually and can greatly complicate the job of managing new component rollouts.
• Contextual Logging – All servers and applications provide some level of logging – but if there is no mechanism to tie log information to users, clients and features, it can require a lot of effort to track down issues. Some sort of contextual information attached to logs speeds support efforts and improves overall customer support and reliability.

Taken together, these features require considerable planning and development effort to implement. They are not part of the core product value a SaaS or Cloud Service delivers, but they make the difference between a business model that operates and scales successfully and one that becomes burdened by too much overhead to scale repeatedly and successfully across enough customers to reach profitability. As you can see, these components will technically scale in relation to the number of clients the service has, not the features in use by clients and users.

SaaSGrid is one of a relatively small number of middleware servers or platforms that vendors can build on to provide these operational features and it will run either directly on servers or as virtualized servers on a service like Amazon Webservices. In either a virtualized or “bare metal” installation, a tool like SaaSGrid can lower the effort required to develop and implement a SaaS or Cloud product by as much as 60%.

So, when we get down to it – fully leveraging the capabilities of the Cloud for an application means understanding component-based architecture, the expected scaling characteristics and use patterns of each component, and finally the “orchestration” or web services messaging that allows all the components to act transparently across many clients as one application. On the business side, all of these elements have to be packaged and modeled to develop client offerings that have prices aligned to value and use. And – building a SaaS or Cloud product means planning for both client and operational functionality.

<Read the previous article in the series<

Do you need to know more about developing SaaS and Cloud Services to develop your application and business model? You should consider joining us at:

How To Eat An Elephant

Developing a Real-World 
SaaS Product Roadmap

28th April 2011

from 8:30 am to 1:30 pm
  (including breaks)

The Venue

Embassy Suites – Southeast

7525 East Hampden Avenue

Denver, Colorado

Prices

• How to Eat an Elephant Workshop – Standard price – $499
• Register NOW for our Denver Workshop and take advantage of our Apprenda-SaaSGrid Special Price
  

Agenda

• The Business Case for the Cloud - Assess if the Cloud is for you by identifying the business opportunity, investment needs, risks, etc.
• SaaS/Cloud Product Strategy – Define the competitive and positioning strategy for your product within your context and your market.
• Your Cloud Business Model - Define how your product will make money and what is needed to make it happen.
Developing your SaaS/Cloud Product Roadmap – Develop a tactical roadmap to align funding, development and marketing objectives.
• Key Technical & Functional Requirements of a SaaS/Cloud Product – Understand the architecture and functional elements required to deliver your service smoothly and profitably
• Cloud Readiness Checklist – Identify key requirements of SaaS and Cloud operations, customer support, legal, financial considerations, sales and marketing that you will need to prepare for to make your product successful.

You can take the workshop by itself or in conjunction with

SaaS University

THE Industry’s Most Comprehensive Cloud Application Conference

At the Embassy Suites, Southeast – Denver, Colorado – April 26th to 28th 2011

Prices

• SaaS University Package – Regular Admission – $999
• SaaS University Early Birds – $799 (Early Bird Registrations On April 15, 2011)

Get an additional discount from Scio – Regardless of when you register

• Because we are participating in this event, you can get an additional $150 off your registration.
• Just enter the Scio’s Discount Code: SCIOsave150 when registering for SaaS University.

Go to SaaS University Denver Registration Page

Over the years since the SaaS acronym was identified, there has been a preconceived notion that hundreds, if not thousands, of SaaS applications would be spawned by independent software vendors (ISVs) from their packaged, on-premise products. It just seemed natural.  Why wouldn’t vendors want to jump on the bandwagon heading into the cloud?

The truth is though, there are still thousands of business-to-business (B2B) applications that have not transitioned and many vendors who have no plans to move their products to SaaS. I found this recent quote relating to hosting for ISVs interesting:

There are thousands of ISVs that have not deployed their application or offered their application as a service.  In fact, only now are ISVs and their customers moving in greater numbers to deploy in a hosting provider’s data center.  The majority of applications in use today are still installed on-premise.

Even more interesting, there are at least hundreds that either made the transition and then withdrew their products or never really embraced the business model, choosing instead to “test the waters” with hosted, single-customer implementations of the same software they sell to their on-premise customers. With all the marketing hype about users adopting SaaS and success in the market for cloud-based services, it is fair to ask:

What’s Going On?

First, let me say, I am not one of those who has a strict definition of “Real SaaS.” Can SaaS architecture be anything other than multi-tenant? In my world, yes. Multi-tenancy has great value for both the vendor and the user community it supports, but that doesn’t make products that are not architected that way automatically less sustainable. Should all SaaS be configurable instead of customized to fit individual needs? I’d say it is preferable but that doesn’t mean there aren’t many other supportable ways to allow customization in a SaaS application. Shouldn’t all SaaS products embrace the social and community product management model we see emerging? I’d say it would be foolish not to consider it, but that doesn’t mean there aren’t many places where it doesn’t fit. But perhaps most controversially, I’ll stick my neck out and say not all SaaS is directly subscription-based nor should it be.

My possibly heretical point of view comes from a simple observation of what we have seen coming to our door. There are many companies today, extending their business models to include online applications. Their customers may pay for access to those applications in addition to their regular service fees, but in many if not most cases, they do not. These applications provide automated access to repetitive services, quick access to online expertise, and process-based systems based on the business services the vendor provides. Are these implementations any less of a Software as a Service application than those of a vendor whose only service is the application itself? Are these services not SaaS because they are bundled into a group of direct services? In fact, because these businesses have fully embraced a service-based business model, is it actually more natural for a them to be successful at SaaS than an ISV?

So, if you haven’t caught on yet, what kind of companies am I writing about? It could be almost any service in any industry. Legal, travel, medical, financial – you name it. Naturally, most will follow the mold of the majority of SaaS companies today and are B2B, but that doesn’t mean that their end users don’t regard themselves as ordinary consumers. Imagine a  medical group, that is contracted by an employer, provides online access to medical advice, scheduling, and preventive care through an Internet-based application. It is paid for by the employer as a part of benefits and used by the employer’s staff and their families. What is the difference between that and the same service provided direct to consumers for a subscription fee by the medical group?  In essence, the difference is the sign up, the payer and perhaps the method of billing. The service itself is just as critical. If the employer-subscribed members aren’t satisfied, they will tell their bosses or HR department. But of course, the same medical group also provides direct medical services and if they offer the subscription-based service through an application to the general public, it can become an “on-ramp” for new clients.

Service In Their Genes?

But that brings up another thought. Do ISVs have the “service-based DNA” necessary for success in SaaS?  Do they clearly see not just the advantage of hosting an application for their clients but also of extending the services that would raise an application beyond a commodity that could be easily replaced by another vendor? Honestly, that is a difficult question. Whether they like it or not, most ISVs are locked in a cyclic-product development mode by their business model. Transitioning to an incremental cash flow with continuous product enhancements is very difficult. Every part of their business is set up to support a fundamentally different direction. We’ve found repeatedly, even when the desire is there, it is very hard for an ISV to change boats in the middle of the stream.

That doesn’t mean that ISVs can’t or won’t transition to SaaS, but I’d say at this point, if they haven’t – the likelihood is increasingly small. On the other hand, if we stop focusing on ISVs and startups as the primary drivers of new SaaS products, we will quickly see there are even more opportunities on the horizon that don’t fit the media-led definition of SaaS. The simple fact is, most companies don’t have to be told what defines the expertise and services they sell. What they need help understanding are the tools and services they can leverage if they want use an internet-based application as a part of their product mix that will lower their development effort and related costs.  They need to know about platforms, cloud-based infrastructure, and development for cloud stacks like those offered by Google, Azure or Amazon.  They need to understand current application user experience patterns and the methods behind SaaS products that are easy to use and adopt. Of course, there is one more thing – they are likely to want other services with the technical expertise to develop and deploy Internet-based applications to fill in the blanks while they continue to focus on their core business.

Do we need another acronym to describe these companies or their online applications? After all -  they are much harder to identify than ISVs. There are many more service companies in the market that could decide to extend their business online but they don’t fit an easily identifiable profile. Should we call them “Service-Based Applications” or something? As tempting as it might be – NO. It is easier to open the definitions of SaaS and cloud-based services to include their business models than it is to come up with an alternative or to just be straight-forward and call them Internet-based applications.

The Bottom Line

The point is we in the industry have to stop being so self-centered. Software developers are not the only ones who can fund, plan and implement a service online. ISVs don’t have a natural or the only path to becoming online service providers. Subscription-based, self-configured, multi-tenant applications are not automatically successful services. Online services are enabled by technology, but generally are not successful as business models if they are based solely on technology. We have to open the doors and let some air in. When we do, we will see there is a lot more opportunity out there than we ever imagined.

So next time you find yourself talking down to ISVs that “don’t get it” – stop and consider. Is it me? Am I cutting out a much larger opportunity for SaaS just because I haven’t included the most likely success stories?

A lot has been said about what Software as a Service is and is not – and we’ve been part of the noise. I really feel however there is something bigger going on. There is a tsunami coming and SaaS is only one of many waves.

People have said SaaS is:

• A delivery method enabled by the spread of low cost broadband
• A technical architecture (multitenancy) that provides higher efficiency and lower costs (in the best implementations anyway)
• A business model led by direct responsibility for service to end-users
• An alternative to the traditional capital investment model of software licensing
• A low cost way to take advantage of applications and services for SMBs
• Gaining acceptance in enterprise business
• A potentially disruptive business model that could end the dominance of traditional software vendors
• An opportunity that allows new players to “level the field” against intrenched industry leaders
• A flash in the pan that will eventually morph into some other even cooler marketing-led hype.

I would say all of these things are true – and more – or less. In another way however, these observations miss the point. An illustration might help:

Business as Usual

In the “traditional software vendor” business model, the buyer is the ultimate customer. If the buyer is a company – no matter how large or small – the buyer is the filter between the people who use the application and the vendor. If you add in a sales or service channel, a secondary source, the relationship with end-users becomes even more tenuous for software vendors.

Think about that.

Most buyers don’t want to be constantly involved with their vendors and the bigger the company the buyer represents, the more that is true. So, if a vendor relationship comes down to a purchase and maybe a license renewal every two or three years – fine. Near renewal time, there are opportunities to push for new features, fix nagging problems, and maybe switch to a new application. Just as often, renewal periods are time to leverage the “choice” to change to get better terms. Even more importantly – renewals are generally concurrent with new product versions so that vendor sales and buyer interactions are orchestrated. Marketing and sales insure that the conversation at renewal time is more about the “new features in this version” rather than the new features needed by specific groups of end-users.

So how is SaaS different?

Power to the End-Users

In the SaaS business model, the “wall” provided by the buyers between end-users and the software vendor is nearly eliminated. SaaS is a service relationship and the vendor is directly responsible for “user experience.” The buyer enables subscription or transaction payments on an expense basis and turns the operational relationship over to the software vendor. Software-delivered-as-a-Service. Oh….

Now the daily concerns about why the application doesn’t quite meet expectations can go directly from the end-user to the vendor and in most cases – since this is outsourcing in reality – the buyer expects nothing less. Put that beside the truth that high renewals are key to survival as a vendor in a SaaS business and you begin to see something important. The software vendor – to be successful – needs to consider a new way of operating.

Enter “agile” product development and “the agile business architecture” stage left.

The same wave that is gradually taking hold in software development is now being adapted to service-based business operations. Except – we haven’t really acknowledged it yet. How does a SaaS vendor insure retention and stay ahead of competition in the dynamic world of the Internet? By eliminating the artificial renewal period version change, proactively engaging with end-users (support), mining the business intelligence that is now in their hands (aggregated usage), becoming the face of a service instead of a label on an install CD (social media and marketing). By co-opting competition and finding ways for them to join in (APIs and marketplaces). By eliminating long design cycles in favor of a system that can embrace continual, targeted improvement and that responds to a changing landscape. By becoming truly Agile for the same reasons the idea has taken hold in development.

The truth is that the problems that became apparent when outsourcing first hit customer service in consumer goods are just as important when an application becomes a service. A service provider who ignores the end-user’s context, that can only respond when you have reached the head of the queue and then only read from user manuals isn’t going to win at SaaS. Creating more hurdles for the end-user to jump over so you have less interruptions during the design cycle doesn’t make you more agile. Being Agile is about flexibility, response to change, and finally responsibility for success at a very individual level.

In a world where Moore’s Law is an accepted reality, where even GM has to downsize to become more competitive – we also have to accept that change is now the constant and we have to rethink how we organize and work. The principles behind the Agile Manifesto are being applied to successful business more and more every day. Because we – at Scio – believe this is a critical subject you can expect more about agile business architecture and for SaaS vendors – how it can be enabled in the application itself – in the future.

As anyone who follows me knows – I use Twitter and TweetDeck to watch the “virtual conversations” about SaaS happening around the ‘net when I can. Today some time was freed-up by a conference call that was delayed so I fired up TweetDeck and took a look around. Imagine my surprise when I read a meme had started around a blog post touting single-tenancy for enterprise SaaS applications.

I’m not going to link to the original post – the writer has his reasons for pushing the idea – they are not entirely wrong, his context is different than mine and most readers of this blog. But I strongly felt the “take away” that might be given to people considering developing a SaaS application was shortsighted to say the least. Without getting into “religious wars” over a complex subject – let me first say that single tenancy does serve as a reasonable tactic for ISVs in some situations:

• Limited instances for a group of large clients that require hosting and will pay the cost differential for an application that really has no direct future as a fully developed SaaS app.
• As a short term response to market pressure and provide an alternative to a competitor’s offering.
• As a beta of a future SaaS application to “get a feel for the market” in a specific vertical where the ISV has not had an offering before.
• …and similar short term, limited implementations with narrow specific goals
• Or when you are using a PaaS like Apprenda’s SaaSGrid that actually leverages a single tenant .Net application and provides hooks to services that can enable the application to operate as multitenant and scale properly.

Let me also say that as Bob Warfield of SmoothSpan pointed out recently – multitenancy in itself is not a solution to all architectural problems for SaaS applications or a guarantee the application can be maintained and operated efficiently. Or – as a friend at OpSource recently pointed out, “A single instance of a multitenant application that just keeps growing forever without the ability to spread across infrastructure intelligently is actually less reliable than a single tenant architecture.” You will know this is happening when you and everyone else using an On-Demand application is suddenly caught dead in the water without a lifeboat by a system upgrade. Even a multitenant application needs to be able to seamlessly operate across several instances to be scaleable, maintainable and reliable.

So to address the most common FUD (Fear, Uncertainty and Doubt) thrown at multitenant SaaS architecture:

• Cloud Computing has solved the problems SaaS application developers need to think about by making it a simple job to put a new instance online as needed and abstracting the “servers” under the application.

Cloud hosting options are in themselves good alternatives for deploying SaaS applications. There is a lot to like about an abstracted infrastructure. Cloud hosting is mature enough for enterprise IT to consider as an alternative to deploying on their own internal infrastructure just as they consider outsourcing other aspects of maintenance and support. But – as an alternative to a multitenant architecture it doesn’t solve the major operational problems posed by individual implementations for each client. For a version upgrade – how long will it take to bring each individual instance through testing and QA up to the current version? Will you be able to move all client instances to the new version in a coordinated way or will the fact that each client has a separate instance lead to a number of “orphans” that fear change and lag by one or more major versions? Will the overhead you face actually prevent you from applying necessary patches and bug fixes until the next “major upgrade?” And what about subscriptions, implementation of instances, payment settlement, self-service, and monitoring of usage? Most cloud-based infrastructure doesn’t address these operational issues and they will all cost you money in terms of overhead as a SaaS ISV even if they don’t cause any support issues and subsequent subscription losses.

• Most multitenant applications use individual database instances for every client so the idea of a truly multitenant application is a myth. Enterprise clients want data isolation and abhor the very idea of “blended data.”

It is certainly true that many SaaS applications have been developed with an architecture that provides an individual database implementation for each client. Whether it is is “most” or not is an unknown – SaaS vendors seldom actually disclose their underlying architecture. However, to extrapolate from the fact that many services are implemented that way because it is what “clients want” is simply silly. First – the idea that single implementations for each client are inherently “more secure” is an answer from a marketing team that has nothing else to say. If there are security risks in the environment surrounding the databases or the way the databases are implemented – single implementations will not lower them unless you believe that by being just “one tree in a forest” you have somehow “spread the risk.” Second – single implementations are inherently less maintainable (see above), have higher overhead costs and are more likely to have delayed implementations of necessary database tuning, patches and upgrades. Delayed implementations mean less security and lower reliability. Third, application upgrades almost invariably require some changes to the database or at least a cycle of testing and QA. Individual implementations mean every instance needs to be updated, tested, and perhaps rolled back if there is an error. It also means a loss of transparency and that some clients may resist upgrades if they are aware of the isolation as a “strategy” (again see above). If this results in database inconsistencies between versions you can end up with application “orphans” again and no easy way to isolate the clients involved without forking your development (and if you don’t know what that means in terms of headaches you’re in over your head).

• Big clients are very concerned about upgrades and want strong control over version migration, especially for applications that are used broadly across the enterprise.

This is certainly true when clients have the primary responsibility for end-user support and system maintenance because the application is locally installed. It is very short-sighted however to believe that a client organization won’t expect the SaaS vendor to accept responsibility for a large part or all of the end-user support and provide embedded training and self-help. This is service offering after all. Would your HR department expect IT to solve problems if Expedia didn’t place a travel reservation for a company executive? SaaS is a form of outsourcing and should be sold as such. If your business model is based on the belief that you can somehow just host the application and leave the support and change control to your customers you should take a moment and read Ben Kepes recent article on the idea that SaaS is just an extension of the old ASP model.

• A SaaS application cannot match the look and feel of their client’s environments or provide ways to be easily customized to fit client operations.

The idea that SaaS applications are somehow required to be “cookie-cutter” with little flexibility is based on a very limited knowledge of current development patterns (or just plain lazy development). Yes, a single code base is a key to maintainability, testing, QA and reliability in a SaaS application. But that doesn’t mean that flexibility cannot be built in from the ground up. It does require understanding what clients might want. It requires allowing a certain amount of “self-service” or at least apparent application “hooks” that services can exploit. On the flip side – if you customize individual instances the risk that a customization will cause incompatibilities rises exponentially in relationship to the number of different customizations. So, as an ISV you have enabled professional services and disabled your operations and reliability.

Finally – the idea that a SaaS application and a premise-based are the “same” should raise flags if you have followed some of the marketing ideas we have written about in the past. Being on the Internet gives applications an entirely different context – if they are not exploiting that idea I would question how much value the SaaS implementation is really giving customers or the vendor.

So – in the end the old adage is true – beware of advisors only carrying hammers to fix problems. They are very likely to believe every problem is a nail…

Addendum –

• The “single-tenancy meme” spread across blogs recently too – read more about the subject in Bob Warfield’s article on the SmoothSpan Blog. It is a well-written response to the misconceptions that have been springing up.
• Bob Warfield of the SmoothSpan blog and I will be talking with Jon Hansen on his PI Window on Business broadcast April 30th about SaaS and cloud-computing and you’re welcome to join us. You can read more from Jon on his blog too!
• The replay of the broadcast is now available on Jon’s site.