Make no mistake: Not everyone has a good early experience with the cloud. The most common problems CIOs encounter come when they discover that they've entrusted the maintenance and management of their software to people who lack the industry expertise needed to run a mission-critical application. This is precisely the realization Jerry Batt has come to about the software-as-a-service arena, and now he wishes he'd had a clearer idea of what factors to consider before he leapt into the cloud.
The CIO of homebuilder Pulte Homes entered the SaaS fray several years ago, when he started moving some of his company's less important systems to on-demand alternatives. Initial experiences with cloud-based applications for managing payroll, human resources, treasury and bond holdings, and third-party legal expenses provided no indication of the minefield he would walk into two years ago, when Batt opted for a large-scale subscription to a well-known customer-service-relationship automation service to manage its relationships with potential home buyers and those in contract. (Batt asked that the vendor's identity not be disclosed.)
At first, everything seemed to go as expected. All the needed features and functions were in place, and those that weren't often were added by the vendor at Batt's request. But Batt says he fell into the same trap he sees other CIOs falling into: He focused too much on those features and functions and how they matched up with business needs, when he should have been looking more closely at how the system would perform during periods of high demand or when the vendor was updating the application.
What resulted were occasional outages that Batt found maddening. "When I have a two-hour outage in a mission-critical application, I can't accept an answer from the provider that's an 'oops,'" he says. "If I ran my shop the way they run this application, I would have been fired."
Batt was so disturbed by this performance that he showed up at the vendor's annual user group conference for some reconnaissance. That's typically the kind of mission CIOs assign to underlings, but he needed to hear first-hand if other customers were having the same issues. They were, but, oddly, they weren't voicing their complaints.
"I said, 'Why aren't you squealing your heads off?'" Batt recalls. "To which they said, 'Well, we haven't put it in front of revenue-producing people.' That told me I might be the only dummy on the block putting a mission-critical application on software as a service."
To make matters worse, Batt's team had built integrations with several in-house applications, including Pulte's contact management system. Subsequently, any downtime in the salesforce automation service also brought down whatever apps were tied to it.
Batt couldn't find anyone to commiserate with on that front. All the customers he talked to said they wouldn't trust the vendor's technology enough to undertake any integration efforts for fear of their in-house applications being held hostage by outages.
Ultimately, Batt decided to have his staff deploy a sort of light switch for its integrations that lets them be decoupled temporarily when the vendor is making changes to its service or Pulte has peak processing needs, such as when it's heavily promoting a group of properties over a weekend. But when it comes to Batt's view of the cloud, the damage has been done. "I've lost confidence in software as a service," he says, "and it's going to take something [major] for me to get it back."
Batt has some words of advice that he hopes will prevent other CIOs from duplicating his experience. Beyond looking at a vendor's functionality match, he says, look under the covers and make sure you're confident they can run the application to your standards. Other tips: Visit the vendor's data center, and talk to other customers to find out what the real service experience has been.