Jaa


Implications of Self-, Outsourced- and OEM-Hosting

The last couple of month I've been talking to many software vendors in China and Singapore and the topic of SaaS hosting is a recurring pain point highlighted by those I met.

More often than not, my attempt to reassure them that my architecture team in Redmond is now feverishly working on SaaS hosting architecture guidance does not seem to appease their anxieties and concerns. (My previous post here described the high level architecture capabilities of a SaaS hosting platform.) I can understand their phlegmatic reactions - hosting is not a core competency for most software vendors and it is no wonder that they are looking for alternatives other than the laborious option of building their own operational capability.

Generally speaking, SaaS providers may consider the following hosting solutions (which can also be thought of as a continuum of options. If you've been following my posts you should now conclude that I really like the continuum way of representing architecture decisions) :

  • Software vendor self host and manage their own operational environment
  • Software vendor partially or entirely outsource hosting to 3rd party hosters
  • Software vendor OEM and license software to 3rd party hosting partners

The right end spectrum of the continuum represents a software vendor's decision to self-host and manage its entire operational infrastructure. The other opposite end of the same continuum represents the decision to OEM and license the SaaS solution to business partners who not only take ownership of the operational responsibilities, but also own the customer relationships with the application tenants. The points between the two ends of the continuum represent decisions to outsource one or more components of the hosting infrastructure to third party hosters. For instance, a software vendor could decide to self host and operate everything except for the billing system which it outsource to a billing solution provider.

For the rest of this post, I want to share some thoughts on the technical and business implications brought about by the above hosting decisions.

When software vendors self-host, they (willingly or unwillingly) become the trusted custodian of their customers' data. The customer data include actual business data as well as workflows and business rules that are configured to run the customers' business processes. The software vendor is (legally and contractually) responsible for the "well being" of the hosted customer data.

Frequently, the self-hosting software vendor is actually sitting on a gold mine of information - lots of valuable business knowledge can be mined from analyzing the stored data. For instance, if the application is an inventory management SaaS application, business intelligence about best selling products of the month and supply forecasting data can be derived by doing trend analysis on the stored data. Therefore, having access to customer's data allow the software vendor to offer valua-add services and information back to the tenants, potentially for additional fee.

Technically, it may also be possible for the software vendor to perform cross section analysis of all the tenants' data in order to generalize business practices used by the clients. For instance, a CRM software vendor may be able to analyse and derive from all the configured workflows, patterns of sales processes with the shortest sales closing period. Such knowledge may then be used in business practices classes offered by the software vendor. Of course, such usage of customer data remains a controversial topic as many tenants will be nervous about their trade secrets being published as best practices.

Publication and resale of identifiable private data obviously violates legal regulations and privacy laws. However, it is debateable if derivation of business knowledge by SaaS software vendor should be permitted, especially if the mining process is non-trivial and involves analyzing large samples of data.  Perhaps we will see more intellectual property protection discussions around this topic when SaaS adopters see their business practices being "popularized" through their service providers. For those who are skeptical about such practices, let me remind you that the financial industry has been capitalizing on customer data and behavior for a long time. (Next time you take a class on stock market trading from an ex-broker, guess where he learned all his best dog tricks.)

The second hosting model frees the software vendor from having to build and operate all or part of the SaaS hosting infrastructure themselves. In most third party hosting agreements, the software vendor would still maintain access rights to their tenants' data, so there should be little contractual restriction limiting the software vendor from pursueing the business ideas mentioned above. Practically speaking, since the hosting is outsourced to third party, there may be technical barriers that needs to be taken care of before the software vendor can have timely access to their customers' data. For instance, the hosting provider may limit when hosted data can be bulk replicated to a data warehouse. This is because the hoster needs to consider the network bandwidth impact on other hosted software vendors when massive amount of (replication) data is being transmitted over the networks.

The third hosting model actually involves a major shift in the software vendor's business model. In this model, the software vendor provides the solution to their hosting partners who host and resell the solution through licensing and OEM agreement with the software vendor. Profit made is often split in varying proportions between the software vendor and the hosting partner. A key implication here concerns the software vendor's access (more accurately, potential lack of access) to the tenant data. In many OEM arrangements, the custody of the customer data belongs to the partner hosters. Obviously this shift of responsibility comes with benefits and downside for the software vendor. While the software vendor is no longer responsible for the operational availability, integrity and security of the tenants' business data, the vendor is also giving up potential opportunities to monetize on those data assets.

In addition to value added services that could otherwise be provided, the software vendor may also be foregoing a channel of knowledge about the application usage and users' behavior, both of which can be accurately obtained through the operational environment. Furthermore, successful Websites often trial test new features by deploying and making pre-released features available publicly on the Internet. Without an operational environment, the software vendor will have to find partner hosters who will stage and trial run its alpha and beta release features.

Although this post may read like I'm trying to convince you that you should be self-hosting, be assured that this is not my intent. There is really no absolute right or wrong hosting model. What's important is that you as a software vendor understands the price and reward that comes with your hosting decisions.

It seems like a lot of good things in this world are bitter-sweet, and now that you are aware of the implications, you'll have to accept that the after taste of your SaaS hosting decision is no exception.

Comments

  • Anonymous
    June 11, 2007
    After spending almost 2 months in China with our valiant Chinese colleagues, Fred is back to headquarters.

  • Anonymous
    June 13, 2007
    The comment has been removed

  • Anonymous
    May 31, 2008
    The last couple of month I've been talking to many software vendors in China and Singapore and the topic of SaaS hosting is a recurring pain point highlighted by those I met. More often than not, my attempt to reassure them that my architecture team i

  • Anonymous
    June 05, 2008
    The last couple of month I've been talking to many software vendors in China and Singapore and the topic of SaaS hosting is a recurring pain point highlighted by those I met. More often than not, my attempt to reassure them that my architecture team i