Courtesy of a news item on InternetNews.com, I learned that enterprises’ desire to offload costs associated with maintaining their own software or storage infrastructures doesn’t automatically mean a boom for Software-as-a-Service (SaaS) vendors. While the technology – the Software – is undoubtedly important, so is the Service. SaaS customers need to be able to trust their vendors.
The article talked about outages suffered by Amazon and how the problems these created for Amazon’s customers were exacerbated by the lack of Service Level Agreements (SLAs) and email support. I was surprised that such a well-known name as Amazon did not have SLAs in place. In the risk-averse industry in which I work – architecture, engineering, construction (AEC) and property – customers have, from the very earliest days, demanded written undertakings about their providers’ uptime, etc.
Selected quotes:
- “It’s important that companies try and exceed expectations and go the extra mile.”
- “It’s much easier to switch from a SaaS application than a normal application because you don’t have to pull out the application and replace it and test it and secure it.”
2 comments
I’m not sure that switching from one provider to another is that much easier for SaaS customers, at least in the AEC business. Once a customer has begun working with a specific system, and has managed to convince all the project participants that they should use it, it’s hard to go back. Even if he wished to do so, exporting and reimporting all data might be a huge problem, knowing that each vendor has its own formats and particuliarities.
I’ve never seen such a case in my 10+ years in the business. Have you ?
From conversations within the NCCTP about migrating data from one system to another, I know that clients have exported data out of one system and then imported it into another. However, this is not an everyday occurrence.
Particularly in a project-based industry, I suspect most AEC customers are content to make a more gradual transition from system A to system B. Ongoing projects can be allowed to finish on the old system, while new ones are rolled-out on the new platform. This eliminates the need for teams to retrain in the middle of a project; if retained to work on future projects, they learn the new system as it is configured to support the next scheme.