“Moreover, the current recession is making the SaaS model more attractive to contractors because: 1) Subscription pricing can easily be added to a project’s general conditions, 2) Low up-front costs allow project managers to avoid an onerous approval process, and 3) Faster and less expensive implementation makes new systems more digestible.”

I couldn’t agree more. The SaaS delivery model is here to stay because it is simply a more efficient and cost-effective model than the on-premise software delivery model.

The Product Manager is primarily responsible for drafting the requirements. Ideally, the Product Manager is a “visual thinker” and graphic designer who can illustrate the requirements and build out all of the design elements and graphics (for more information about illustrating requirements click here). Developers should be able to build directly from the requirements. Requirements must be “signed off” by the Product Owner before development commences. The Product Manager also assists with the launch of the product, including training, user guides, marketing, etc.

The Product Owner is the business person ultimately responsible for the product. She works closely with the Product Manager to ensure that the product is being designed correctly and that her vision is being realized. The Product Owner has the final say in design decisions and reviews and approves each completed feature.

The Development Manager manages the development team and ensures that each developer is productive and that the team hits its deadlines. In addition, the Development Manager is responsible for architecture, database design, resource allocation, task management, coding standards, release management, application configuration, IT, and quality control.

The Development Team consists of Developers and Testers. They are responsible for coding the application and keeping it bug free through continuous testing. Ideally, all of the design is done by the Product Manager but there may be a need to also hire a Designer.

That’s it! No need for expensive specialists such as architects, systems analysts, DBAs, scrum masters, database designers, release managers, etc. Instead I recommend hiring generalists as managers who can wear multiple hats and only hire specialists for the actual coding.

Here are some pricing model ideas:

• Monthly flat “service & hosting” fee – A flat monthly fee could be charged. Flat fees can be adjusted up or down based on the number of users.
• Usage based – A fee could be charged based on some usage criteria. For example, the vendor could track each record that is created within the system by a customer and then bill that customer based on total records created during a month.
• Feature based – With an “a-la-carte” system of adding and removing features/modules, vendors could assign a cost value to each module. Then, they could use determine how much to charge per-module, per-month.
• Free - Vendors can always take the free approach and make money through advertising. A good example of this model is mint.com.

These are the SaaS pricing models that I am most familiar with but I welcome additional ideas. Please feel free to submit comments!

Data Aggregation

Ok, I know I said I wouldn’t talk much about the benefits of SaaS because we want to focus instead on design and implementation in this blog, but there is one important benefit that is often overlooked and under appreciated; data aggregation. Inherent data aggregation is unique to SaaS, and can only really be accomplished efficiently with a multi-tenant model.

Data is quickly becoming a valuable asset. Many companies base their entire business models on the quantity and quality of their data. But in order for that data to have real value, it needs to be aggregated, analyzed, and presented in a meaningful way. Vendors/ISVs of SaaS applications are sitting on loads of data entered by thousands of customers. With a multi-tenant model, this data is already aggregated and ready to be mined, analyzed, and presented. Of course, one of the challenges is that the data must be “de-identified” and “anonomized” before it can be presented, but this is a relatively simple process.

Imagine for a moment a SaaS application for grocery stores. Many different grocery stores use this application to track and manage their inventories. Now, suppose that one of the grocery stores (maybe from a large chain or maybe a “mom-and-pop” store) wants to compare its restocking times for specific items against other grocery stores of similar size and geographical location. Well, this grocery store is in luck because the software vendor has provided, as one of the benefits of this inventory management SaaS application, a de-identified report comparing restocking times, in aggregate, of each store with other (competing) stores. Basically, this equates to an industry “trend analysis” report, but it is much more relevant, timely, and trusted because the data is real-time, localized, and generated directly from the source. Other types of companies, such as healthcare providers, could benefit from comparing results of their surgical procedures against a de-identified, aggregated group of similar providers. This powerful feature can provide a compelling advantage for a company to “purchase” a multi-tenant SaaS application over another type of application.

Another opportunity for the SaaS vendor is to sell rights to view and mine data to 3rd party companies. With the right tools, 3rd party companies can have access to robust trending data and possibly even discover new trends that haven’t been previously considered within the vast amounts of data.

And, why not consider placing ads within the SaaS application itself, like FaceBook does? SaaS vendors could lower the fees they charge in exchange for the acceptance of ads (just like Gmail). These ads could be highly targeted based on the data that has been aggregated and analyzed behind the scenes.

One possible hangup in this whole strategy is that customers want to “own” their data. This is understandable. But, there is no reason why customers wouldn’t agree to let their vendors use their data in an anonomized and de-identified manner, for legitimate business purposes, especially when it provides value back to the customers.

So, wake up SaaS vendors/ISVs to the inherent data aggregation benefits of your mutli-tenant SaaS applications!

But what about the fact that SaaS applications are browser based and hosted? Well, other single-tenant applications can have those same attributes, so they are not differentiators. In fact, in one of my prior companies, we had trouble with competitors claiming they were “browser based” and “hosted”. We tried to differentiate ourselves based on the fact that we were multitenant (multi-tenant), but it was difficult when our competitors threw around terms that are often used to describe SaaS applications.

So, what is the most popular multitenant application?  Well, probably Facebook. Millions of people log in to the same database (yes there might be multiple servers hosting a huge database but you know what I mean). There is a single database schema (i.e. structure) for all customers and a single code set. Each person has his/her own little customized page and can make changes without affecting other pages. This is a classic SaaS application.

Since multitenancy is THE differentiating factor for SaaS applications, we are going to spend a lot of time on the subject in the SaaS Fans blog. And, have no fear SaaS fans. Multitenancy offers such as compelling advantage to software vendors/ISVs that it merits its own unique software classification (i.e. SaaS).

My vision for SaaSFans.com is that it will be a source of “best practices” and practical knowledge on designing, building, and deploying SaaS applications. We will rarely discuss the benefits and drawbacks of SaaS (there are plenty of other blogs for those discussions). Instead, we assume that you have already embraced the SaaS model and just need some help to get started on actually turning your vision into reality.

Other than the information provided here and any feedback that I can provide, if you would like some help actually building your SaaS application my company Surge (www.surgeforward.com) can help.

So, to all you SaaS fans out there, let’s share our ideas and turn our SaaS visions into reality. My plan is to post tasty morsels of SaaS knowledge at least every week so check back frequently.