SaaS Week

The differentiation between true SaaS and hosted traditional software has been the subject of much debate, and recently I was joined by Paul Giurata of Catalyst Resources for an interesting discussion about the matter, plus tips that companies can keep in mind when developing a SaaS solution. Listen to the podcast or check out the transcript below.

Download file

KD: Hi, I'm ebizQ's Krissi Danielson. With so many studies finding that companies plan to implement On Demand software, it's no wonder that so many companies are trying to get into SaaS, but there's a right and wrong way to do it. With us today is Paul Giurata, a managing partner with Catalyst Resource, a company that offers user interface and application design for critical software applications for some pointers to keep in mind when developing a SaaS application.

Now Paul, there is a lot of debate around distinguishing true SaaS applications from pretenders that seems to try to take traditional software and make it SaaS merely by hosting it remotely. What do you think is the key difference between these two categories?

PG: The difference is in the amount of functionality that has to be exposed to the user. So in a real true Software-as-a-Service application, you -- if you can imagine you have the application itself in the middle that the user interacts with and then there's sort of this constellation of about ten or so different things that need to be addressed like that the user still needs to experience.

So for example, purchasing it, deploying it, customizing it, provisioning and add users. In a true Software-as-a-Service application, all of that needs to be sorted out. And it makes the application much, much more sophisticated. Where as if you've got just a hosted application where someone said, well, we're just going to host this, similar to a lot of we saw in this early ASP model that the provisioning, the administration, the purchase, the support was still all done via normal model.

Well, we'll have our professional services people do. We'll run it as a separate code base, you'll have your own version of it; it's on your own server so that's the biggest difference. The other thing that is relevant is that when you do Software-as-a-Service, in order for it to be scalable, you really need to be able to have one code base you're working from. Where as in these sort of imitation versions where they're just going to web enable some. They might web enable let's say some scheduling piece of software, TRS, and there is a separate version of the application you need from each customer that is running and that's not a scalable business.

KD: Okay. So what would you say are the biggest mistakes that companies tend to make when they try to jump on the SaaS bandwagon?

PG: It's related to my previous comment, which is they don't understand that when they're looking at the application and they want to move to Software-as-a-Service that there is this constellation of other experiences that need to be addressed. They don't take that into consideration both from a complexity - from a technical complexity point and effort point so that's one of them. The other thing is that much of what's driving people to want - much of the drive for Software-as-a-Service are for applications that are either desktop based now like, for example, Intuit's QuickBooks.

KD: Right.

PG: I know people that have that be Web-enabled for a number of reasons, or very complex enterprise applications that could be ERP. I mean that's a very sophisticated application, but it could let's say a flight planning piece of software, or payroll piece of software. And what's inherent, those pieces of software is they are very, very complex so and the experiences that people need to have when they interact with the software is very, very complex and sophisticated.

So the mistake that organizations make is that they're not aware and they don't quite understand that to turn those into Software-as-a-Service is really is going to require much of this rich internet application behavior that there is so much discussion about. And I think people don't realize that that's going to be a key design point, and they go into these initiatives not understanding how to address and design the software as a rich Internet application.

As an example, you know what I mean by rich Internet application. I mean where there's a lot more manipulation of data on the screen, people can do real-time sorting and (inaudible), filtering and there's a lot more interaction right there at the screen as opposed to a traditional web application where the entire screen refreshes so it's a lot of this AJAX type behavior.

KD: So it sounds like maybe companies that want to deploy SaaS should be reading up on the Web 2.0 trends.

PG: 2.0 trends, life would be specific to that. The Web 2.0, which is such a loaded term -

KD: Right.

PG: - also has a number of different things in it. And I think companies need to really understand are what are the rich internet application behaviors.

KD: Right.

PG: So for example, if you look at something like FLEX, there's a lot of that rich internet application type behavior in that particular technology.

KD: Right.

PG: That's most of what I'm referring to.

KD: Okay. So for a company that wants to deploy SaaS, particularly, like in ISV, what are some key points they should keep in mind when they try to put their offering together?

PG: Well, I would say it would be the two that I mentioned. One is to realize that when you have an existing piece of software and you are going to web enable or move that to Software-as-a-Service, there's this constellation of experiences that you need to consider right up front and they relate to. And I'll even kind of mention, the purchase cycle, deployment, customization that people will be asking for, provisioning, how you add users, that sort of thing, training, support, billing, monitoring to make sure that you can deliver the service levels, delivering service levels.

And another key aspect of it is being able to update the software on probably a no more than 90 to 180 day cycle as opposed to one year or 18-month cycle. So that's the constellation of things that are sort of surrounding the piece of software. And then the other thing that I would recommend is our sense is that there is significant demand to do these things Software-as-a-Service applications. And the enabling technology that has appeared is really this rich internet application behavior.

We won't be able to do Software-as-a-Service and deliver these complex - what were historically enterprise-level applications there were own an internal network and running off computing power of a PC as well as a server. We won't be able to deliver that just via the browser, it's really going to take these other rich internet technologies that are being presented in a browser but are much more compelling to be able to do that.

KD: Great. This has been ebizQ's Krissi Danielson speaking with Paul Giurata of Catalyst Resources. Be sure to tune-in at www.ebizQ.net for more podcasts, whitepapers, blogs and other latest updates on SaaS and Enterprise 2.0. Thanks for listening.