By Craig Smith
The construction company I work for wanted project management software that could quickly and easily share information between all of our offices and remote job sites. But the thought of using an application service provider (ASP) made me more than a little uncomfortable. I was particularly concerned about:
- Allowing someone else to control the data our company uses on a daily basis.
- Security of the data.
- Establishing an SLA (service level agreement).
- Internal support for a product that could change at a moment's notice.
- Hidden problems and costs.
The sales pitch
“ASPs will save you money.” CFOs and CEOs are hearing this preached to them wherever they go. Usually, people who are trying to sell this product make that cost-saving argument. The marketing folks say ASPs are the natural progression along the thin client computing path. The argument is that it helps manage the all-too-overused, theoretical TCO (total cost of ownership).
Our problem in the construction industry is that we are somewhat of a niche market. Any software designed specifically for our use is quite expensive. Our second problem is trying to use this software at a remote job site, where communication comes at a premium. For these two reasons, an ASP seemed appealing.
The grand total for obtaining project management software under the old-fashioned payment plan would be about $30,000. I could see the benefit of not having to fork over that chunk of change to get up and running on new software or to upgrade existing software all at once. But the other side of the coin is that you never own anything. If you walk away, the only thing you may own is the data you entered while using the software. And if you discontinue using the product but still want to manipulate the data you created, where does that leave you?
Using an ASP reminds me of the cellular phone commercial where the driver of a car is stopped and a man with a vacuum cleaner sucks all the money out of the driver’s pockets. It also makes me think of the car repair commercial where the repairman says, “You can pay me now or pay me later.”
Dealing with ASP troubles
Despite such concerns, we selected the ASP project management software. I didn’t get to choose the service provider, but I was assured that this was the best choice at the best price. I was given the project, so it was my job to make it work.
As always, things didn't go as smoothly as advertised. The product was supposedly compatible with the more recent versions of Netscape and Internet Explorer. That's where the headaches began!
First, I attempted to set up our company information and check the data we'd sent the ASP (they did import our data from one of our current programs—one kudo for them). I made a couple of changes and selected save, but nothing seemed to happen. I tried some refresh options, and still nothing.
I discovered that to get this process to work, I had to make some adjustments to my browser. I had to force it to look for a newer page each time the page came up in order to see the most current information.
Next, I started hearing complaints from our handful of guinea pig users. They told me that not all of the information was showing up. After talking with the ASP’s tech support and trying several options, I was able to get most everything to work most of the time by using the Netscape browser instead of Internet Explorer. The problem was related to the way IE's Java code works and how it was affected by our firewall and content filtering. I had to set up an exception rule on the firewall to bypass that function.
Then, I needed to fix the problem of display settings. Any adjustments, such as choosing an extra large font or setting screen display to the wrong size, caused certain drop-down menus to disappear. I hoped the ASP would resolve this soon, because anyone with eyesight problems was going to have trouble with this program.
Finally, it was time to address the real heart and soul of the matter—speed and data integrity. I wanted to ensure that what we created would be safe during and after transmission. Even though the ASP had provided the necessary first step of making sure a username and password were required, they seemed to have overlooked the possibility that I could be “hijacked” on the Internet.
The ASP refused to use SSL for all data being transmitted. The reason? This would affect performance, and the ASP considered the information not sensitive enough to require this extra layer of security. Much of our data is just meeting minutes and requests for information, but there is also data that includes contract change orders and other financial information. I found the ASP’s security precautions totally unacceptable.
We know there are security risks and assume that we all are going to play nice and not exploit them. But denial of service and other attacks are not going away. We're not only putting our personal information at risk; we're putting the security of multimillion-dollar companies on the line. The ASPs want us to save documents, calendars, and other business commodities on the same server that thousands of other companies are using. Our data becomes a prime target, because if all the data is shut down, it could cripple many companies at once.
Companies who use ASPs are ignoring such risk. From my viewpoint, the construction industry has generally taken security very lightly, and other industries likely do the same. We have begun using advanced technology so fast that we still marvel over the wonder of being able to have access to so much. No one has adequately considered the security consequences. Maybe that will happen when we have to start throwing money at a problem we knew existed the first time a password was stolen from an AOL account.
The future of ASPs
The ASP I dealt with earned a couple of positive points, including:
- They worked with us to make the product as functional as possible and listened to our input.
- They attempted to provide a product that could deliver a wide range of functionality while making it useful to the job at hand.
But their view on security and inability to be a true “thin client” application from the “zero end-user administration” end lead me to conclude that an ASP can be nothing more than a fad. The concept needs to be reworked. The industry needs to listen to IT professionals and their concerns. Besides security issues, our experience with an ASP showed us it didn't meet our needs. The investment in an upgrade was more expensive and more involved than we wanted. Only with changes will this cost-saving idea make sense in the real world.
ASPs are used mostly in small to medium-size businesses. Will they ever make sense for major corporations or the consumer markets? What’s been your experience with ASPs? Post a comment below or send us a letter.