This site is a static archive of the Aegir community site. Documentation has moved to http://docs.aegirproject.org. Other community resources can be found on the Contacting the community page.
Skip navigation

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

Help

Software-as-a-Service Business Model Specification

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 topic of 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

Need help?

Documentation

The notebook section provides a way for you to store and share information with your group members. With the book feature you can:

  • Add book pages and organize them hierarchically into different books.
  • Attach files to pages to share them with others.
  • Track changes that others have made and revert changes as necessary.
  • Archive books that are no longer of interest to the group. Archived books can be reactivated later if needed.

The revisions let you track differences between multiple versions of a post.