Scenario #3: Managing the re-sellers hosting plans in the store front to include software items from the new application

When & who?
There may be multiple store fronts offering the same underlying software items for sale in different packages and price models. Each store front has a business/sales manager responsible for composing plans/packages using software items and services from one or more sources, setting price per time period for eh plan etc.

How?
Each store front has its own catalog implemented of any technology the store front happens to chose. In our store front implementation, the catalog is a service implemented using Windows Communication Service (WCF), but other store fronts may choose to implement their catalog on top of an ERP system. Our catalog stores information about what software items are available, their dependencies and their license schemes. This data is read from the platform service’s inventory and the underlying platform/application manifests. In addition to software items, the catalog service also stores information about services, such as e-mail support, phone support, domain registration etc. The catalog service is then able to keep track of these software items and services in any possible combination in a plan with an associated time period and metering info (more on this in a later post about metering and billing). As an example the store front could offer a “Small business” plan that look like this:

·         two software items with a fixed fee per module and month from ISV A

·         three software items from ISV B with a fee per “application object” (i.e. books in a book store application, pages in a CMS application, number of hair dressers in a salon application etc)

·         domain registration/renewal

·         e-mail support

·         12 month at X/month or 24 month as Y/month

The 1^st stab at a simple catalog data model we implemented in our sample looks as follows:

Image 1: Catalog data model

The business/sales manager at the store front works with one plan at time, but the plan may contain software items from multiple vendors potentially running on different platforms located in different hosters data centers. Our architecture allows for these complex scenarios by

·         Clearly separating the three roles (store front, ISV/platform tenant and platform provider)

·         Having a service interface through which these three roles can interact and

·         Having the catalog automatically refresh its software items from the platform as they are being used during plan management.

With this design, the three roles can be played by any number of business entities (two store fronts for the same applications on the same platform, one store front for two applications on two different platforms etc). However, to make life keep it simple and comprehensible in the short lab, we chose to use a simple but realistic (remember there’s a real hoster, a real re-seller and a real ISV with a concrete business problem participating in this lab) setup:

·         one store front re-selling

·         two applications from two different ISVs (or platform tenants) running on

·         two different platforms provided by

·         one platform provider (i.e. using one platform service)

as shown in the illustration below:

Image 2: Catalog & plan management

Looking at it in terms of call sequences, catalog and plan management looks like this:

Image 3: Sequence diagram for catalog & plan management

The first call is there because we discussed the possibility of having a product manager at the ISV side maintain an XML doc (using some fancy product configuration tool obviously) with the suggested packaging (i.e. “Standard” includes these 50 modules with the usage limits and “enterprise” includes these 200 modules with no usage limits etc). We thought it might be useful if the applications are complex and if the re-seller mostly follows the suggested plans, but decided to skip implementing it for now…

Next step
With the current SaaS maturity level, SaaS ISVs start-ups will pick up the phone and call the hosters sales department. However I believe that, in a not so distant future, SaaS ISVa wants to shop for hosters just as a SaaS consumer shops for applications. I also believe that many start-ups want to start small & inexpensive and the upgrade to “premium” platform services later. Therefore I believe SaaS hosters should package their platform in to “subscribe per year” type plans just like applications – i .e. offering a “bronze”, “silver” and “gold” SaaS hosting platform plan as the following example:

·         Bronze: Hosting on a shared platform with data on a shared stand alone SQL server

·         Silver: Two load balanced web servers in virtual machines and data on a clustered SQL server with an entry level SAN with service level of X.

·         Gold:  Two or more load balanced web servers in physical machines, published through two load balanced application proxies and data on a clustered SQL server with and top notch geo-dispersed SAN with service level of X*2.