SaaS Primer

I've been working on building a new Yard/Dock Management/Appointment Scheduling application (hence the lack of blog entries). Our plan is to offer this application as both a traditional in-house hosted app and an externally hosted SaaS model. In that spirit, here are some SaaS articles that I've been reading:

Architecture Strategies for Catching the Long Tail is a great primer on SaaS and the issues you will face when adopting it.

Top Ten Reasons Why On-Demand Services Will Soar in 2008 - the title is pretty self-explanatory.

On Demand Gaining Traction in Supply Chain (PDF) from Aberdeen Research has some good information about the adoption of SaaS in the suppy chain software space.

On-Demand/SaaS Reality discusses SaaS pricing and its adoption in the enterprise.

Dashboard in the Cloud?

Software as a service (SaaS) or running applications "in the cloud" is all the rage these days. I've been thinking about the applicability of that model to dashboard software. To be clear, I'm talking about an application that is hosted by someone other than the company that is using it, not just subscription-based licensing, which is a different issue.

The advantages of SaaS for dashboard software for the user are not much different than for other applications: lower IT costs, less up-front cost, easy (theoretically) upgrades, potentially better security and scalability.

However, there is a big difference between a typical dashboard application and something like a CRM system: the data. In a dashboard app, the data typically comes from many other systems. Whether it's real-time or batched the data has to get from inside the firewall to outside the firewall where the dashboard lives. That opens up a big can of worms in terms of security and performance.

On the performance side, a dashboard that pulls data from a relational database would now be going over the net which is going to increase the latency of the queries. Depending on how those queries are designed and the speed of the link, this could be a huge performance hit. The same thing would apply to a dashboard that pulled data off of a message bus. There would be less of an issue if a "push" model was used where some process that lives inside the firewall sends data to the dashboard app. But now we've moved some functionality inside the firewall and back into the hands of IT which decreases the benefit of the SaaS model.

Also, the data seen on the dashboard is now going over the public internet and is likely stored in a database living at the hosting provider. This is a security risk that will have to be carefully managed, but it's not an unsolvable problem. The data can easily be sent encrypted and the dashboard itself can support https so the data can't be intercepted on the way back to the end-user's browser. The database issue is mainly a matter of the trust you have in the hosting provider so the application vendor better do their homework when selecting one.

Microsoft has published a good primer on these kinds of issues and SaaS in general. It's not specific to Microsoft technologies and the first parts are not too technical.

Despite the issues, I believe SaaS does have potential for dashboard software. In cases where collaboration among multiple companies is a requirement, such as CPFR, many of these same issues would have to be addressed anyway. In those situations, the chances are good that a hosted solution would be forced to solve the problems in a better way than a traditional install. So I can