Revision of Software-as-a-Service Business Model Specification from Mon, 09/19/2011 - 01:17

THIS DOCUMENT IS A DRAFT

The Software-as-a-Service (SaaS) model allows clients to purchase subscriptions to pre-built sites (whether pre-packaged profiles such as Open Atrium, or custom-built profiles), which are then provisioned for them by an Aegir system.

In the Aegir-based Business Models session at DrupalCon London, I outlined a number of business models supported by Aegir, with a particular focus on SaaS.

My intention with putting together this roadmap is to plan and then deploy a reference implementation at openatria.com. Basically, this comes down to "one-click" sites that, in it's simplest form (from a customer stand-point) bypasses Aegir all together.

Order Workflow

1. After perusing the service catalog, the client decides on an Open Atrium site and adds it to her cart;
2. She then decides on some options, such as:
   1. Extended features (i.e., experimental, in-house or 3rd party custom features, &c.);
   2. Premium themes;
   3. A quota on the number of users (users seems like a good basis for estimating resource and support requirements);
3. She decides on a level of support (e.g., 8x5 vs. 24/7, phone vs. email vs. forum, automated backup frequency, &c.);
4. She pays;
5. She then receives her welcome email from her new Open Atrium site, where a user account has already been created for her and assigned the role of "manager".
6. Finally, based on her level of support (from step 3), she might be granted access to additional resources outside her site, such as the ability to submit support requests to the service providers issue-tracking system.

Details

• The client needn't ever see Aegir.
• She is not assigned UID 1.
• No doubt other options will also need to be made available such as:
  • Level of security, possibly w/ bundled SSL certificates;
  • Use of a subdomain vs. new domain name registration.
• Service levels may not need to use uc_hosting or Aegir, per se. They could perhaps be handled by building product kits (i.e. Community/Business/Enterprise levels);
• As noted in step 6 above, access to additional resources (i.e., creating a user account and assigning a role on some other site) could be handled by some other mechanism. However, if this mechanism was implemented in or managed by uc_hosting/Aegir, it could allow for other interesting possibilities, such as a free/cheap/demo package that simply creates a group (in the context of OA) for the client, rather than a full site.

Modules

Several modules are already under development to support these features:

Hosting Profile Roles

Assign uid1 to an admin user, and give a role to the created client user.

User Limit

Limit the number of users on a site. The plan is eventully integrate with User Role Limit, so that quotas an e assigned per role.

Registrar API

Provides a drupal form to register domain names with a pluggable back-end to support various registrars.

Hosting Support

Keep support clients in sync with the aegir clients created by uc_hosting.

Hosting Subdomains

Alter the site creation form to only allow the creation of sites using a subdomain of a specific domain.

Hosting Services

Allow uc_hosting (and thus all of Übercart) to run on a separate Drupal site.

Additionally, some modules are currently only in the planning phase:

Provision Profile Roles

Drush extension (back-end) to support Hosting Profile Roles.

Hosting User Limit

Provide a quota on the number of users on a given hosted site. Requires User Limit to run on the site, and refactoring on the current Aegir quota system.

Provision User Limit

Drush extension (back-end) to support Hosting User Limit.

Hosting Expiry Date

Schedule disabling and/or deletion (after backup) of sites after a certain date. Eventually, to integrate w/uc_hosting an uc_recurring.

Provision Expiry Date

Drush extension (back-end) to support Hosting User Limit.

Other useful contrib modules are already in production use: * Hosting Queue Runner * Hosting Backup Queue * Hosting Backup Garbage Collection

Notes

This is based on an initial spec I wrote last year: http://groups.drupal.org/node/94959#comment-306609