Diane's cost concerns re: cloud and SaaS may be missing a key point: cloud lets you test an idea for a small app quickly and inexpensively. If it works you can scale it with some other hardware if you need to.

Our research (at CogniTech) strongly suggests that IT effectiveness (not efficiency) depends more on doing a lot of small apps that meet a business goal than on the big killer apps that take 3 years.

So cloud's chief virtue is providing a way of bridging the gap between emerging business goals and IT's perennial lack of resources for their achievement, NOT low cost.

Diane's comments are valid; however, the comparisons are more than likely very elementary. Cloud computing holds the promise to disintermediate a number of entire industries. Now, is there a cost to that? Of course, and there should be.

The key questions are, what are the trade-offs, and which benefits are important to the consumer? In the example of a client-server application consuming a "cloud" can mean that appliation developers have nothing to concern themselves with regarding the back end - all they care about is talking to the cloud provider's API, and everything else is take care of. What is that worth?

Also, all of the infrastructure specialists who architect, deploy and maintain servers, maintain uptime, business continuity, etc., have been eliminated. What is that worth? There are too many factors involved in cost justification; its complex. But as more services come online, the choices will be enough to cause more confusion to potential consumers.

Recently, I have been following cloud technology with interest and purposely because I'd like to introduce it in our environment, but I'm skeptical of its cause effect. Perhaps Tom or Peter can asnwer a question for me or, for that case, anyone else: what about security? The threat of hack will exist as long as humans will have the ability to create (anything); we can invent measures to prevent violations but they will never be eradicated, the cost continues to be exhorbitant. How will cloud computing will deal with security? I'd like to know.

I would agree with Tom. Time to market is key in these tough times. You don't want to spend a whole lot only to find that you are down the arong path. With cloud computing, SaaS and open source, you can go to market with new concepts and prove them in no time.

I would even state that this is not only to prove concepts but can be thought upon as the future in this fast changing world. Before you realize that you have created the best for your business users, you are obsolete and have to start all over or be out of the race.

And, like everything else, the costs will go down as competition increases. To pick an example, to host a Web site sometime back it would have cost you $100+/month and now you can have something for as little as a dollar a month.

I think the bigger issue with cloud computing is that there needs to be a change in scope of what "computing" is for a good ROI.

Consider email vs paper letter. You could (and when email first appeared, people did) send an entire 5-page letter, the same as you did with snail mail, but that's not the best use of email -- shorter sharper correspondences are key. Similarly, with the shift email to IM, again you could send an entire email. You could, but you shouldn't.

Cloud computing will have the same issue if people try and do exactly the same thing (send a 5-page letter via IM -- not likely to win friends) rather than focusing on the purpose of the function (and re-scoping the function to deliver that function with the change in frame of reference).

My $0.02 worth.

I think Peter brought up several valid points. In my organisation, we have been examining the costs of adopting SAAS and cloud computing on several fronts. The results are almost always the same -- within 3 to 5 years, the costs of SAAS will surpass the initial up-front implementation fees of a traditional setup.

But SAAS/cloud is still a serious consideration because, like Peter said, there is more to the consideration that just pure financial figures. One big factor for us is how our business is going to evolve down the road should we adopt cloud computing. That alone means a lot more to us than financial figures.

I have a question for folks who have done the cost analysis (3 to 5 years, the costs of SAAS will surpass the initial up-front implementation fees of a traditional setup).

Did your research consider hardware upgrade cost at the end of 3-5 years (when your servers go out of warranty)? This might be an important factor to consider as well.

More business oppurtunities + cost of hardware upgrade may still justify the cloud cost.

RE: Security - S Ramos had a question on security. Most SaaS vendors or providers put a lot of emphasis on connectivity, robustness or their applications, and security. Without having solid security, their business would lose all credibility -> losing customers. So it has to be solid.

The other way I look at SaaS providers' infrastructure vs. in-house is this -- if the customer is medium to large, and they are not in the business of hosting software (e.g., you are not travelocity.com or someone who's business relies on Internet), then your budget and ability to have a robust infrastructure, relative to a solution provider is not going to be as solid. A service provider can leverage multiple customers' needs and with economies of scale, justify very strong security measures that might be out of budget for a company trying to do it for itself.

Of course, make sure you are working w/ a reputable company. There are a lot of SaaS vendors popping up these days. I believe most of them realize how critical a good infrastructure is though.

AD-

I agree with comments regarding the ability to quickly and easily provide small applications. That is a big advantange and one of the primary reasons I support SaaS.

I work in healthcare and we have literally dozens of "small" applications geared toward the needs of individual hospital departments (labs, therapies, etc.). So we are very familiar with the process and costs of implementation.

One thing about my comments are that they are comparing applications purchased from a commercial vendor, not applications coded in-house. I would think the cost analysis of SaaS vs. in-house development might have very different results.

Regarding the components of our costing model.
We are pretty comprehensive in our model and include:
costs of server replacements;
ongoing architecture maintenance;
in-house application support;
vendor maintenance fees;
labor costs for support and upgrades;
power in the data center;
license upgrades for databases, etc.

I hope this helps clarify. Bottom line to me is that the SaaS monthly fees never stop, while the client-server model has a big spike in year 1, then a lower cost on-going.

RE: ROI / Analysis in 3-5 years. To chime in here... I would echo Shailesh here. In cloud computing, you are always on the latest version of software (no patches, no upgrades) and robust hardware that gets upgraded regularly. So every 3-5 years, a company would either continue to run on old hardware, or if it tried to upgrade software and hardware, incur more capital investment.

It takes a specific case to find the real answers, but a good portion of the ROI in SaaS is around 'soft costs'. IT or management has no headaches about patches, upgrades, down servers, warranties, etc. Its hard to gauge or justify these time savings in some cases unless you look at IT more strategically.

AD-

Some folks are lumping different offerings together -- cloud computing and SaaS. Cloud computing is more infrastructure and environment (e.g. Amazon's S3 storage service) and SaaS is an application (e.g. Salesforce.com).

Both offerings have their advantages and disadvantages over in-house provided services, but the main advantages are faster time-to-benefit for cloud/SaaS, ability to experiment (edge vs core computing), and simplification of your operations group (subject matter experts, admins, software, infrastructure, etc.).

As with any IT solution, it depends on the nature and functionality of the application and the pricing structure. Vendors need to rethink their overhead structures. They must also set prices that deliver healthy, sustainable client ROI because long term profitability depends on customer retention and healthy subscription volume.

In terms of cost comparisons, it's good to remember that when you host on internal gear, not only do you need to put up new hardware and replace it in 3+ years or so, but you also need hardware for test (e.g. patches), integration or system testing, user acceptance and / or pre-production staging environments, not to mention database instances, albeit clusters help. And resource time like DBA's, system admins or application specialists to refresh data from production so tests can be representative.

Or you might not bother with that and experience the nice surprise of promoting an untested patch or unproven upgrade and quickly wish you had.

Btw, at the company I work we employ a multi-sourcing model. Major apps like ERP and CRM are on company infrastructure with robust non-production environments, while lesser apps like online expense reporting and employee performance mgt are SaaS.

The sheer effort of maintaining non-production instances (in addition to production) across the multitude of apps is good motivation for SaaS. Less complexity to manage and balls to juggle - and that is something that appeals to many I expect, not to mention faster time-frame to benefit and the potential to promote a culture of calculated and cost effective risk taking.

But the question to ask SaaS providers is whether they can and will maintain such environments on their end for you. E.g. to perform integration testing when you have changes in your internal company environment which might impact the SaaS app - or vice versa.

Integration and customization requirements are other factors to consider. Unless APIs are truly robust and proven, SaaS is less appealing where intense or even moderate functional extensions, customizations or integration requirements come into play.