Lars Fløe Nielsen

So, i’ve just gotten home from the EasyFair ICT/Internet EXPO held here in Denmark, - a fair where Sitecore was represented on a booth with one of our partners (Pentia). I wasn’t on the booth myself, but rather visiting other boots and to hear some of the exiting panel debates and other interesting stuff.

Jesper Lykkegaard, sales director, Pentia (left) and Thomas Kirk Albert, CEO, Pentia (right) engaged in a discussion with a customer (center).

 

I followed a lot interesting discussions and presentations, - and wont’ go into details on them except for a very cool presentation by PwC security.  They managed to hack the VoIP of a (fictive) company, through a scenario where the target didn’t have direct access to the internet, but only the Intranet (who were using the same SQL as the internet server in the DMZ). The intranet server was even behind yet another firewall. They used SQL injection on the public web server to upload files to the intranet, then vulnerability in WinZip to install the snoop the stream of the VoIP system…. Very cool, - and very scary.

 

Anyways, I too was invited to participate in a panel debate around SaaS with some very clever people. The topic was a series of questions, especially if the customers would want to use this technology and/or if the ISV’s would build software that will work with SaaS.

 

So what were the overall topics?

As a whole, we all agreed that Software as a Service is here to stay. Companies will want to use rented software in a higher and higher degree: SaaS will make it easier for small companies to use software which may be hard to maintain and run (e.g. they can rent MS CRM instead of purchasing it, installing it and run it). Even large companies will seek benefits, as parts of the organization, e.g. marketing, can rent features for a while (e.g. campaign software) without the need to clear this with the IT department. Naturally we also discussed that some applications have to be cleared with the IT department: Usually business critical systems. Here’s an example: An IT department may not object if the marketing department rents a small web site for campaign purposes (for example 2-3 months), while they most likely would object if the marketing department chose MS CRM instead of the Corporate SAP CRM as this will defragment the data, and render the synergies of a shared customer database obsolete.

 

However, we also discussed what could put a lid on companies desire to invest in SaaS: Security. For example, if a major SaaS (e.g. the CRM SalesForce) should be unfortunate to publicize one of their customers entire customer database, exposing this to the customers competitors. However, Anders E. Trolle-Scultz also came with an interesting observation… SaaS might be safer for most companies because the ISP and ISV would be focusing on security for that particular software, while the small company most likely would not have this kind of expertise.

 

I had a topic I wanted to discuss: I didn’t believe the question if the ISV’s are ready for SaaS should be asked, but rather a more broad question; will the ISV’s get ready with SaaS enabled software, and when they are, can they get the software hosted somewhere?

 

The fact is that almost no ISP’s are ready for SaaS. Naturally you can design a solution, then have an ISP host it, - but it requires much more than that. The hoster should deliver a framework which can automate processes for installation of the ISV software, - ordering software for the end customer etc.

 

Now, some ISP’s have actually purchased a SaaS framework, e.g. DK vendor Cohaesio, but I really don’t think this will kick off unless a SaaS framework and process description is ready. For example, can we all agree on one framework, then the ISP can install it, - and the ISV can code their applications up against it.

 

Fortunately, Microsoft has picked up on this challenge, - and started their SaaS incubation center as the only major vendor on the market. And hopefully, - at some point, they will supply a full SaaS framework the ISP can install on their servers, and a set of rules that the ISV must code their applications up against. Imagine a scenario that if so, the ISV’s can go to any ISP (who runs the framework) and deliver their software on a CD. Then the ISP can start offering the software within a day.

 

Another good note was made by Bjørn Skou Eilertsen from Microsoft. He believed (and I concur) that companies in future would use a combination of Software as a Service (that is rented and serviced software), along with Software + Services (the ability to have your application installed locally, then have the application use services online, e.g. MS Outlook having contact details updated automatically through a remote directory).

 

Abbreviations used in this article:

ISP: Internet Service Provider. A company specializing in hosting solutions.

ISV: Independent Software Vendor. A company that produces software.

SaaS: Software as a Service.

 

Related Articles:

SaaS incubation project

Uh, I know I promised to report from the Microsoft Worldwide Partner Conference 2007, - also during process. But to be honest, I have not had the time to do so.

 

We’ve been clogged at the Sitecore gold sponsor booth with hundreds of visitors. Potential partners, potential customers, business analysts, Microsoft staffs, - and from all over the world. Here's a picture of the booth BEFORE it opened.

 

This year the majority of the Sitecore booth staff came from our US office, while we still had channel managers from both UK, Nederland, Denmark, International sales, and naturally from the corporation also, running up to a total of 14 staff members, plus two very charming greeters. At times all 14 members was fully occupied, and some even with more than one visitor. Here some of us are walking the streets of Denver in search of a restaurant.

 

 

Personally I have not had time to participate in any labs or sessions, even though there were a few I would love to have seen. In the other hand, I have been talking to so many interesting and clever people ranging from major corporations like Microsoft, to smaller specialized companies. They did have one thing in common though (despite their obvious great relationship to Microsoft); they all knew directly where to position themselves. For us, this means a more qualified visitor.

In the evenings, - all of them, I’ve been at various events; Danish partner event, global partner event, booth events etc. Here’s a picture from our Danish event, - the directors speaking from a stair to the crowd.

 

What's the Microsoft message? 

The message from Microsoft, - both Ballmer and everyone else this year was Software plus Services (for example, they launch a hosted edition of Dynamics CRM named Live CRM) and that partners should focus on selling the software that was released last year. Nothing new software though, except their Microsoft surface (http://www.microsoft.com/surface/) which looks so overly cool, and demos that well, but which I really have a hard time see fit elsewhere than Las Vegas casinos. For example, would you be using a travel planner with the size of a table instead of your mobile phone?

 

Anyways, - I hope to get home now and get a chance to absorb all the impressions. And, - hopefully blog more about it…

Other articles on the SaaS project

The Software as a Service (SaaS) Project
The SaaS project - part 2 - challenges and provisioning
The SaaS project - Part 3 - Plans and plan management
The SaaS project - part 4 - Orders and Operations
The SaaS project - part 5 - Metering and billing
The SaaS project - part 6 - Federation

 

5. METERING AND BILLING

The tenant has purchase a “per usage” service. How do we bill her?

Let’s assume that the hosting providers offering of the ISV software is based on a per software item usage, e.g. per Sitecore document, or in a CRM system it could be per account. How can we build a generic interface that allows the hoster to get this information from the ISV software on a per-tenant-basis?

 

The application manifest offers metering points, the plan defines which to use

The different measuring offerings for a given piece of software are usually decided by the software itself. Sitecore, for example can configure and measure limits on a per item level, per concurrent content author, the total of content authors, per database size, etc.

The application manifest, which holds information about requirements for a piece of software as well as the actual installation script, also contains a metering section with zero or more metering (web) services for the software item.

 

<am:monitors>
  :
  <am:metering>
    <am:usagemetering type="applicationitems"
      id="SC_ItemCount">
      /sitecore/itemcount.asmx?tenant=$(tenantname)
    </am:usagemetering>
  </am:metering>
</am:monitors>

 

When the hosting provider defines the plan, they also configure the pricing models. Each pricing model for the software will define the rules of the billing routine, such as “every month, check on the (max) content items, then bill the tenant 5 cents per item”. This rule will point to the metering point, ruled by the manifest.

The plan naturally can reside in any database, but in XML it could look something like:

 

<Plan>
  <Item id=”SCBox”>
    <MeteringPointIntervals>
      <Point id=”SC_ItemCount” Refer=”x” meteringInterval=”24h” />
      <Point id=”SC_DBUsage” Refer=”y” meteringInterval=”1h” />
    </MeteringPointIntervals>
    <LicensePacks>
      <LicensePack name=”LowFlatHighItem">
        <Limitation type=”flatfee”>2$</Limitation>
        <Limitation type=”Items”>0,5$ * $SC_ItemCount</Limitation>
      </LicensePack>
      <LicensePack name=”HighFlatLowItem”>
        <Limitation type=”flatfee”>20$</Limitation>
        <Limitation type=”Items”>0,05$ * $SC_ItemCount</Limitation>
      </LicensePack>
      :
    <LicensePacks>
  <Item>
  <Item id=”SCBoxMailing”>
    :
  </Item>
  :
</Plan>

 

Measuring intervals

Naturally, the hoster could choose to use the metering point web service once a month, but this would allow the tenant to decrease the number of content item every month right before the hoster read the value.

To solve this issue, the hosting provider should supply a measuring (windows) service that, with regular intervals (also defined in the plan) can use the measuring web service and store this value in a measuring point database.

When the hoster has defined the plan, and publishes it to the front end ordering system, the plan management system also generates a plan interval manifest.

The windows services operate from this plan interval manifest and as such the service simply receives a number of operations, executes them and stores the return value into a database. E.g.:

 

<?xml version="1.0" encoding="utf-8" ?>
<PlanManifest>
  <Plan name="Premium">
    <SoftwareItem id="Sitecore" intervalMinutes="10">
      <MeteringPoint id="SC_ItemCount" tenantId="customer1"
        action="http://sitecore/itemcount.asmx?tenant=customer1"/>
      <MeteringPoint id="SC_ItemCount" tenantId="customer2"
        action="http://sitecore/itemcount.asmx?tenant=customer2"/>
    </SoftwareItem>
    <SoftwareItem id="SitecoreMailingList" intervalMinutes="15">
      <MeteringPoint id="SCML_Mailboxcount" tenantId="customer1"
        action="http://sitecore/mailboxes.asmx?tenant=customer1"/>
    </SoftwareItem>
  </Plan>
</PlanManifest>

 

Once a month, or when the plan defines to bill the customer, they will query the measuring point database through method with an interface looking something like:

 

float GetMeeteringPoint (
    MeteringPoint, TenantID, StartDate,
    EndDate, AggreegationType)

 

Where the last parameter, aggregation type is allowing, sum, count, average, max and min values.

When the plan management system receives this value, it can calculate the max number of items and add this with the agreed upon price.

 

CRM or ERP integration

This process can be initiated from the CRM or ERP system (which too can be connected to the ordering flow), or the billing engine could be a separate piece of simple software which passes the data to the CRM.

The hosting provider must be aware of the potential need to deliver billing information to any 3 part billing provider; this could be a service provider who’s an expert in collecting fees, or it could be the ISV who must handle invoices.

Other articles on the SaaS project

The Software as a Service (SaaS) Project
The SaaS project - part 2 - challenges and provisioning
The SaaS project - Part 3 - Plans and plan management
The SaaS project - part 4 - Orders and Operations
The SaaS project - part 5 - Metering and billing
The SaaS project - part 6 - Federation

 

3. ORDERS AND ORDERS MANAGEMENT

A customer (tenant) purchases a product (the application).

The previous post described how to address the plan building. A plan is referring to one or more software items in the application manifest. When the hosting provider publishes the plan, tenants can start purchase the service.

The orders management is closely related to the ISV and hosting provider’s agreement: In some cases, the ISV would want to sell the software, in some cases its being done through the hosting provider. For example, Sitecore would want to sell the basis Sitecore software themselves as it’s from a price perspective in the high end, whereas Sitecore box, a tool based on Sitecore, might be an option on the hosting provider’s platform as costs for a web site is very low.

Whoever sells the software should provide an interface for orders fulfillment. This interface should obtain overall information from the plan, but upon purchase it should intercommunicate with the other part; Sitecore to hosting provider and vice versa, with information about the current order.

Furthermore, the system should communicate to the Platform service with a notification to initiate provision of a new tenant for the selected software item. The provisioning system would copy files, move data and execute web services according to the instructions in the application manifest for “tenant installation” for the software item.

In the Sitecore box case, the platform service would look at the application manifest, and execute a single web service (requiring a few parameters, e.g. domain name and tenant name); where after Sitecore box would create a new web site in the platform.

 

4. OPERATIONS

The hoster uploads the service level agreement by keeping an eye on the tenant’s application.

This is also a very important key feature, when hosting applications: The honoring of service levels. For example, most hosters provide an up-time and break-down notification whenever somebody hosts their application at the hoster.

It’s obvious that most hosters must somehow monitor the web site, or in the SaaS environment several different web sites. This can be done through traditional monitoring tools, such as Microsoft Operations Manager (MOM): The monitoring software checks at regular interval one or more pages to see if the page has the expected result (otherwise the page or site may be corrupt). Also the monitoring software, e.g. MOM can get some information from the Windows Performance Counters.

This is very essential for your software application, if you want it to be ready for SaaS; make sure that your application, upon installation, configures several custom performance counters such as “data count”, “number of users”, “memory consumption” etc.

Naturally Sitecore does this, but in addition Sitecore also supplies even more services for checking the health of the application, or even parts of the application. Sitecore has a web service which can check for multiple elements of the application; for example the speed of the connection to the SQL server, if a sub site is healthy, if security has been truly locked down and much more. The idea is that the monitoring software can call this web service and immediately get several issues checked up upon through a simple XML response (where each topic can be rated, info, warning, error).

The application manifest, holds information on relevant performance counters for each software item. For example, Sitecore has more than 80 relevant performance counters that are being offered to a hosting platform. Other applications, such as Sitecore Box which can hold an unlimited “tenants”, or sub sites, generate a single performance counter which returns the number of items per tenant. An item in the Sitecore terminology is equivalent to a document.

During the SaaS project, one of my colleagues, Sergey Marchenko, attempted to generate a MOM installation package directly from the application manifest. This IS feasible, but as the SDK for MOM is extremely new (in fact under documentation and development), we did not succeed due to time pressure. However, it is worth pursuing: Imagine a scenario where the hoster’s operations system automatically is being updated from the ISV’s abstract description document, the application manifest without human interaction!

Keywords: Microsoft Operations Manager (MOM).  

Other articles on the SaaS project

The Software as a Service (SaaS) Project
The SaaS project - part 2 - challenges and provisioning
The SaaS project - Part 3 - Plans and plan management
The SaaS project - part 4 - Orders and Operations
The SaaS project - part 5 - Metering and billing
The SaaS project - part 6 - Federation

In my last post, I explained about the platform management system and the provisioning engine. This post will describe the plans and plan management service.

 

2. PLANS AND PLAN MANAGEMENT

Hoster defines what to sell, and publishes it to the orders system.

When the hoster has imported the application manifest and the platform diagram into the platform management system, they will need to define a number of plans. A plan is a single or collection of software items referring to the application manifest. For example, the hoster may not want to offer all the software items the ISV supports, but instead select some of these and combine it with the hosters own services (up-time services, back-up plans etc.).

The hoster can make any plan as long as they honor the rules of the application manifest. Let’s assume the following dependency hierarchy in the Sitecore manifest:

• Sitecore CMS
• • Sitecore Box
  • • Sitecore box forum
• Sitecore mailing list
• Sitecore Forum

If the hoster decides to sell Sitecore box forum, the manifest would also force the hoster to include the Sitecore Box and Sitecore CMS in then plan as box is based on Sitecore as well as the forum only runs in a Box environment.

The hoster could create a number of different plans:

• Sitecore box (would automatically require installation of Sitecore)
• Sitecore box forum (would require the tenant had first purchased the Sitecore box)

The hoster must also define how to bill the user; for example, a plan could be based on a per editor usage, or per item usage (e.g. 1 cent per content item per month). This means that the plan must refer to a valid software item (e.g. Sitecore) as well as the metering service that allows this plan (e.g. a Sitecore web service that can return the number of items for a web site usage). This adds another section to the manifest; the metering counters.

When the plan or several plans has been defined by the hosting provider, it’s published to the front end shop where regular tenants can select the service.

As an ISV it’s optional if you want to supply one or more plans for the hoster. This would be beneficial for the hoster as a plan would refer valid metering points.

Other articles on the SaaS project

The Software as a Service (SaaS) Project
The SaaS project - part 2 - challenges and provisioning
The SaaS project - Part 3 - Plans and plan management
The SaaS project - part 4 - Orders and Operations
The SaaS project - part 5 - Metering and billing
The SaaS project - part 6 - Federation

As I wrote in my previous article, “The Software as a Service (SaaS) Project, Sitecore has been involved in a SaaS pilot project, keyword “the SaaS incubation project”.

The role of the software provider, the company that provides the software as a service, was in this project split between the company that hosts the software, Cohasio, and the ISV, Sitecore. Other operations, such as large corporations might both design the software and host the solution themselves, are being the full software provider.

Microsoft, in the other hand was trying to solve the frequent challenge of bringing a piece of software towards the hosted platform: Easier installation, better operations (daily surveillance and maintenance), upgrade paths, billing (e.g. per month usage etc.).

THE PRACTICAL CHALLANGES

As an ISV, you must know what the hoster need to run their operation in order to create a successful application built for hosting at a “remote” location. For example, a piece of software must supply various measuring points allowing the hosting provider to check the health (and current temperature) of the application.

In the other hand, the hosting provider too must support other interfaces; reporting to the ISV, notifications when the system fails, gets slow or unstable, etc.

Some tasks are shared; ISV must supply their software along with a long range of instructions (security configuration, database creation, database connection, file copying etc.), while the hosting provider must on every single installation spend time executing these instructions.

The Microsoft SaaS framework will define a number of interfaces each player must implement, but otherwise know very little about the other side operation. This will allow any ISV, - like Sitecore, to pass their software to any hoster, like Cohasio, along with a single transparent instruction set (manifest). The hosting provider on their side will need nothing more than their physical server setup (e.g. a Visio drawing), then apply the manifest to it; viola: Installation, monitoring, reporting… all running. Or so is the vision.

The elements of the SaaS framework

During this process we identified and solved the following six challenges. This “shorter” description will not go in-depth, but will be explained in later articles:

1. Provisioning: Initial software installation and installation each time a tenant purchases a service or a software item.
2. Plans and Plan management: Hoster defines what to sell, and publishes it to the orders system.
3. Orders: A customer (tenant) purchases a product (the application).
4. Operations: The hoster uploads the service level agreement by keeping an eye on the tenant’s application.
5. Metering and billing: The tenant has purchase a “per usage” service. How do we bill her?
6. Federation: If the tenant has purchased several different software items, how can we ensure that the tenant only need to log on once for all applications?

1. PROVISIONING

The task  of installing a piece of Sitecore is usually handled through our executable Microsoft Installer which installs files, attaches SQL (or other database), and creates a new web site on your IIS installation. During the installation process, the administrator are prompted a number of times, e.g. for file location, SQL connection string, new domain name. Also, in order to install through the MSI, you must log on to the local machine as a user profile with sufficient install rights (e.g. local administrator).

This is usually not an option for many hosting companies; manual operations and granting full rights to an “unknown” application for installation would usually pose a problem. Also, it’s not a very effective approach to distribution on a entire hosting platform as well as it does not take care of creating new domains etc.

Provisioning systems

Most existing hosters have solved this issue by implementing a provisioning system; this system can be configured to copy files from one location to another, configure security settings, create domain names etc. Microsoft has an entire server product, Microsoft Provisioning System (MPS) which is a series of dedicated servers. The current challenge of this approach is that the hosting provider must define these operations for each individual piece of software.

Traditionally this is solved by the ISV supplies a document with instructions in human form. The hoster processes the instructions manually for the software in their provisioning system.

Manifests

For the research project, we identified, and generated a method to pass this information from the ISV to the hosting provider in a unified format, called a manifest. The manifest contains installation instructions on one or more “software items” and the relationship between these. For example Sitecore basis installation and Sitecore Box which is a solution built on top of the Sitecore CM Framework.

The manifest also contains much more instructions that described above. Each software item defines a requirement specification (e.g. “test access to a SQL server”), an initial installation section (when the hoster want to offer the software for tenants, what should be installed before first tenant signs on) and a tenant installation section (what should we do, when a tenant purchases the software; in Sitecore box we execute a web service and create a new domain).

MVP vs. LPS vs. other provision systems

During the project we discarded the MPS as an option, as this would require a real live setup and much more resources than our team could afford during the three week. The system configuration was simply too much work for a POC, but would be an excellent choice in a live hosting environment.

Also, if the idea of a provision idea should catch on for hosters and individual ISVs who would play the role of a hoster as well, we decided to implement our own provisioning system; the Lightweight Provisioning System (LPS), which can be installed on a single Windows 2003 or Vista server. Simply install Windows PowerShell, and then attach the 8 custom PowerShell commands.

For all fairness I need to explain that other provisioning systems can handle the same task as the LPS and MPS, not necessary based on the Windows platform. Also, most existing hosters have already adapted these systems.

The ISV and the manifest

If the ISV has designed the software ready for SaaS (see other requirements), all the ISV need to do is to define the manifest once, then pass it to any hosting provider (which is “ready for SaaS”) along with a source CD.

The hoster and the manifest

The hoster must ensure their provisioning system “understands” the manifest; this might require initial configuration or manifest transformation to the selected platform. I’m sure Microsoft will supply a method allowing the MPS to understand the manifest. Naturally the LPS already understand and can execute the manifest.

Platform diagram and platform management service

The hoster must also design their physical server architecture in an XML format (in our case we did it in Microsoft Visio 2007); draw the servers (e.g. 4 web servers, one SQL cluster, with IP real numbers) then store this Platform diagram as in the platform management software.

The platform management software has several purposes, but in reality it’s a thin piece of software whose sole purpose is to deliver and store different data structures and pass these documents to other systems. For example, the hosting provider uses the platform service to store a new manifest or platform diagram, or execute the provisioning of the manifest with either initial installation or tenant installation.

When the platform management system is asked to initiate provisioning, the platform services finds the appropriate manifest and the platform diagram in the database, then merge these two documents into a single XML document (set of instructions for each server; some for the SQL server, some for the IIS-servers). This document, the provisioning manifest is then passed to the provisioning system.

Provisioning

The provisioning system (in our case, our LPS, written in PowerShell), receives the provisioning manifest and simply executes the instructions (in Sitecore’s case, copies the files, create domain names, add IIS site, assign security to folders, attach databases to SQL server, configure ASP.NET web.config etc.).

Whats next?

You can read more about this scenario at Michel Baladi's Blog, "SHP #5: The first two scenarios – the a basic meta-data “goo” (define, map & persist)". 

Jimmy Rasmussen has written an excellent Blog post on LPS and the techniques. Read this to build your own provisioning system: http://blogs.msdn.com/jimmytr/archive/2007/03/17/saas-in-... 

Next articles in this series will describe the different elements identified as part of the SaaS challenge (Plans and Plan management, Orders fulfillment, Operations, Federation etc.).

Keywords

Lightweight Provisioning system (LPS), Microsoft Provisioning System (MPS), Windows PowerShell.

Other articles on the SaaS project

The Software as a Service (SaaS) Project
The SaaS project - part 2 - challenges and provisioning
The SaaS project - Part 3 - Plans and plan management
The SaaS project - part 4 - Orders and Operations
The SaaS project - part 5 - Metering and billing
The SaaS project - part 6 - Federation

The last three weeks, I and a very skilled team of developers and architects have had the pleasure of visiting the Microsoft Technology Center, just north of Copenhagen.

The purpose of this project was to build a proof of concept on Software as a Service, and at the same time cover and define some of the standards and elements that would be required in Software as a Service setup.

The participants of this project was Microsoft Technology Center (EMEA), Sitecore and a hosting provider, who each gave input and developer resources to cover five major scenarios.

The next couple of weeks, I will cover these scenarios through several Blog posts, as well as relay the experiences from an ISV perspective in a SaaS environment.

What is SaaS?

Software as a Service (SaaS) means delivering software over the Internet. Traditional companies have been running their own infrastructure, purchasing, installing and maintaining their software. In the SaaS scenario, a company, the software provider, is responsible the application (installation, maintenance, scalability, availability etc.) while another company, the tenant, pays for these services.

The tenant

The benefits from the tenant are obvious, regardless of the size of the company: The risk of software acquisition is greatly reduced and the company will not need to invest in application operations knowledge. It also means that the company for a time being can test the application in parts of their organization, and if successful, instantaneously roll it out to the rest of the organization.

However, there may also be drawbacks; costs of renting the software, especially for large scale companies may exceed the proprietary approach of traditional software acquisition. The organization must also trust the software provider to handle potential compromising data. Also, the ability for integration between the company’s existing software and the SaaS software may be decreased greatly.

Gianpaolo Carraro and Fred Chong from Microsoft have written an excellent article on the adaption of SaaS from an enterprise perspective.

http://msdn2.microsoft.com/en-us/architecture/aa905332.aspx

The software provider

The benefits from the software provider are obvious; the application target market share is often increased and it’s possible to centralize upgrade and maintenance, hence reduce support for older or outdated versions of your software.

Risks also applies to the software provider; solutions built for SaaS require special architecture, and for existing ISV’s these requirements may end up in rewriting parts or the entire application.

The hosting provider and the ISV

While the most popular examples of SaaS, such as salesforce.com (www.salesforce.com) hosts the solutions themselves, this may not always be the case. Smaller software companies, or software companies that solemnly focuses on the product itself, such as Sitecore, will not be able or willing to configure a hosting center. In this scenario, they will be depending on a 3 part hosting provider. In this case the software provider is divided into two entities; the ISV and the hoster.

The SaaS incubation project

The SaaS incubation project is all about these 3 parties, and the requirements for these entities: The tenant renting the application. The ISV delivering the software, and the hoster, naturally, hosting the software.

In this article series about SaaS, I will thrive to describe the requirements for SaaS and the various aspects and scenarios that must be covered.  With a twist: It will be from a ISVs perspective; what the SOFTWARE must support.

Do not expect to learn everything about SaaS on this Blog. It’s my personal experience as lead solution architect that are relayed; Sitecore, Microsoft or the hoster is quite innocent.

As a final (personal) note

As a personal note, I must grant my highest regards to the developers that have been involved during the entire project; Sitecore and Sitecore Express very dedicated and professional developers, Søren and Sergey, Microsoft Technology Centers awesome team; Michel, Jimmy, Mario, Kevin and the 3 hardworking developers from the hoster (whom I cannot not mention at this stage). Also, my regards to the other involved advisors that have been willing to spend time on our project.