Cloud Computing vs. SaaS | Mass Customization in the Cloud

SaaS Do #8 Enable Mass Customization is a core principle for building SaaS applications. Salesforce.com, for example, has taken it to new heights with offerings such as the Force.com platform. However, do SaaS-based development platforms such as Force.com represent a fundamental shift in application development, or are they simply the SaaS equivalent of Microsoft Visual Basic for Access? How do they stack up against cloud computing platforms like Amazon Web services? This post examines the potential for competitive advantage through mass customization in cloud computing vs. SaaS.

The short answer is this…
Mass customization in cloud computing is more natural, more flexible, and offers more potential for competitive advantage than in the wildest dreams of SaaS, because cloud computing is built on Web services that are a) inherently abstracted, b) independent components and c) accessible at every layer of the technology stack.

Note: In a previous post, I claimed that the salient difference between SaaS and cloud computing is that SaaS has largely been about Internet applications used by people, whereas cloud computing is about Internet application components used by other computers. More succinctly, Websites vs. Web Services. Although everyone seems to have their own definition of all the cloud buzzwords, I’m going to be rather specific and equate them as such: Cloud = Internet, SaaS = Websites for human users, Cloud Computing = Web services for computer users. My intent is not to debate or define the industry terminology, but simply to keep track of what the heck I’m talking about here at Chaotic Flow.

The Role of Meta-data in Mass Customization
Mass customization in SaaS is achieved by converting hard-coded application functions into meta data configuration settings.  For example, multi-tenancy converts hard-coded deployments of multiple customer databases into a single database infrastructure where each customer deployment is identified by a unique customer ID. All the technical miracles that distinguish one customer’s data from another customer’s data are abstracted to this single piece of meta-data to enable data-driven functionality like Customer[1].Name = “Company X” and “Customer[2].Name = Company Y”. Voila!  Mass customization = meta data abstraction of functional capability.

More Natural – The Inherent Abstraction of Web Services
Mass customization is more natural to cloud computing vs. SaaS for one simple reason: meta-data abstraction is inherent to Web services, but it is optional for websites. SaaS applications must be carefully architected to enable mass customization at all, i.e., it is a matter of good SaaS application design discipline to employ a multi-tenant database, configurable security settings, customizable page views, etc. In contrast, every function of a Web service is inherently abstracted to meta-data in the XML inputs and outputs of the API.

The Xignite stock quote Web service can return a wide variety of information
such as the current stock price, an intraday stock chart, and financial news
that varies by the stock symbol (meta-data) supplied to it.

For example, given a particular stock symbol (meta data), the stock quote Web service above can return a wide variety of information about a company such as the current stock price, an intraday stock chart, and financial news. Let’s say Company X above is a manufacturer that uses this Web service to create a website with detailed, current financial information about the company for potential investors. Now let’s say Company Y is a Web publisher that uses this Web service to create a widget that provides in-line stock quotes for companies discussed in its news stories. Here we have two completely different applications built from a single Web service. Imagine trying to architect this degree of mass customization into an end user SaaS application, i.e., a single Web application that can present anything from a detailed company financial profile Web page to a single stock quote widget simply by changing application configuration settings. Sounds like iGoogle to me. Not easy.

More Flexible – Independent Components vs. Monolithic Applications
The stock quote example above also demonstrates the flexibility of enabling mass customization through independent components over that of a monolithic application. Changing a single feature from hard-coded to configurable in a SaaS application can require modification and refactoring at every layer of the software stack from the database structure to the user interface, e.g., adding user-defined custom fields. Moreover, the introduction of  new configuration settings can have a multitude of known and unknown impacts on existing and seemingly unrelated features, e.g., changing an address format from a standard US postal structure to a configurable structure that better supports international clients. The result is that even the simplest modifications to a SaaS application must be carefully considered and become more difficult the more complex the application.

Web services are relatively independent, loosely coupled components. New functions can be added to current Web services, and entirely new Web services introduced with minimal impact on other Web services. For example, I use Google’s chart Web service to generate the charts on the SaaS Model Scorecard. If Google wants to add new chart types to this Web service, it simply creates new values for the “cht” parameter and any other relevant options. However, a SaaS charting application would require changes to the UI to select the new chart type, select the new chart type options, visually edit the new chart type and display examples of the new chart type. Depending on the architecture of the application, this could be a modest change or a monumental change.

Moreover, independence allows customers to assemble solutions from best-of-breed components more easily. The stock quote web service above supplies the data and charts, but the UI can be constructed using the customer’s tool of choice, including any SaaS application that supports Web services. Application integration across functional silos has proven to be a consistent challenge for SaaS companies. Most have turned to open APIs, i.e., Web services to address this challenge. The more a SaaS application opens itself through Web services, the more it acquires the flexibility for mass customization available to native cloud computing solutions. Pushed to the limit, it can become difficult to tell the website from the Web service.

Wildest Dreams – Morphing Applications and Infrastructure, not Just Features
Imagine building a SaaS application that could magically morph from CRM to ERP through configuration settings. The complexity of building such an application is staggering, not to mention the subsequent configuration. Again the Force.com platform comes to mind. Now consider cloud computing. Let’s say I store the respective CRM and ERP application executables on Amazon S3. And, I create a Web service with two calls: gimme CRM and gimme ERP. When I log in, I select ERP or CRM. This Web service automatically downloads the specified application and instantiates it on a farm of Amazon EC2 virtual server instances, where it can be accessed from the URL www.elastic_crm_or_erp.com. This neat trick is possible, because Web services allow mass customization at every layer of the software stack. In this particular case, the configuration reached down below the application layer itself to the O/S and swapped out the entire application. From the user point of view, I just magically see my website change from ERP to CRM.  This approach is really overkill for this simple example, but it makes clear the ability of cloud computing to handle meta data driven, ad-hoc modification at any layer in the technology stack.  It could just as well be accomplished at a much higher level in the stack using two SaaS applications and a single sign-on…uh, Web service.

Mass Customization and Competitive Advantage in Cloud Computing
Although cloud computing offers greater potential for mass customization than SaaS, cloud computing does not really compete with SaaS. Amazon AWS and Force.com are unlikely competitiors, because they segment the market into the high-end and low-end of mass customization respectively, and customers will choose one or the other according to their requirements.

Like SaaS, cloud computing competes against on-premise software, offering many of the same benefits such as lower TCO and mass customization. But unlike SaaS, cloud computing does not compete head-to-head for a final end-user applications. It competes for components at every layer of the technology stack from storage to user interface. As a result, the competition centers around architecture as much as outsourcing. While SaaS adoption is usually driven by functional executives, cloud computing adoption is driven by IT executives. Adopters of cloud computing must rethink how they build applications, employing interchangeable components that may or may not exist within their own firewall. In order to overcome this barrier, cloud computing vendors should leverage mass customization to offer their customers orders of magnitude improvements in functional versatility, deployment flexibility and infrastructure elasticity in addition to lower TCO.

Comment on Facebook!