A little bit of cloud computing goes a long way

Dear Bob …

Am I an old fogey, or just old enough to know better?

[ Confused by the cloud computing and SaaS hype? Read InfoWorld’s “What cloud computing really means” | Get sage advice on IT careers and management from Bob Lewis in InfoWorld’s Advice Line newsletter. ]

I’ve been hired as CIO for a company that’s past the startup phase but not yet beyond entrepreneurship. It’s big enough to be international, both for suppliers and customers — we pretty much do business in all time zones. It’s a great place to be after too many years buried deep in a behemoth IT organization.

I say “CIO,” but I’m pretty sure I’m here to provide adult supervision. My team is young (from my advanced age, I’d swear many of them are truants from the local high school), enthusiastic, and smart. They’re terrific.

From my perspective, they haven’t yet scored the scars that lead to good judgment. From their perspective, I’m way behind the times.

What I’m referring to is the decision, made by this team with my predecessor, to build most of the company’s application portfolio from SaaS (software as a service) vendors. They tout all the reasons listed in the brochures: OpEx instead of CapEx, on-demand scalability, universal access via any device with a browser — you know the drill.

I don’t want to squash their enthusiasm or suggest I don’t respect their opinions. On the other hand, the thought of relying on this architecture scares the hell out of me.

What do you think? Am I just too old to learn new tricks? Or are they too young to have learned enough of them?

– Geezing

Dear Geezing …

You might be too old to learn new tricks, but this isn’t a symptom. The SaaS marketplace is just fine for providing one or two point solutions, and even for providing a complete ERP suite if NetSuite will do the job for you.

Go much beyond this, though, and you’re looking at just enough sources of trouble that you’ll probably want to limit your exposure. They are:

• Manageability
• Change control
• Root cause analysis

One at a time: Assuming you want to know about problems before your users do — one of my criteria for professional IT operations — you’ll need a third-party management application to keep an eye on availability and performance. This one isn’t a show-stopper. It is an added expense, and if your management software does report a problem your ability to resolve it will be limited by your SaaS vendor’s responsiveness — which isn’t a given. Many SaaS vendors figure that if their server is up, then they’ve lived up to their side of the contract.

Change control is a more serious issue. Unless you’re satisfied going back to the olden days when we had islands of automation, you’ll have multiple interfaces connecting the SaaS applications you use. By itself this isn’t so awful, assuming you choose SaaS vendors who have built integration points into their architecture.

Where it becomes dodgy is when one of your SaaS vendors decides it’s time for an upgrade. If your due diligence was done well, your contracts are airtight, and your vendors are conscientious, they’ll let you know in advance. That’s very nice, except for the niggling little detail of how you’re going to regression-test the upgrade before it goes into production. Few SaaS vendors provide test versions for this purpose in advance (I say “few”) because I haven’t researched this topic thoroughly enough to say “none” with confidence.

If you are able to regression test, you still won’t be in a position to reject the change if you find it breaks something else in your environment.

As there have been more than one known situations where SaaS vendors have changed their APIs without informing their customers in advance, I’d call this one a serious issue.

Then there’s root-cause analysis. When something does go wrong with your environment, you’re going to have all the usual problems with mutual finger-pointing among your SaaS vendors, because that’s what vendors generally do. In SaaS land, “up” doesn’t usually mean end-users can function. It means the SaaS vendor’s servers are up and the application code running on them reports a heartbeat.

Those of us who have been around a while know this doesn’t always mean everything is just fine. Quite the opposite is often true, and troubleshooting a multivendor problem is enough of a challenge when everything is in your own data center.

I haven’t even mentioned the challenges you’ll face if you have to schedule big batch runs that merge data from multiple vendors (I haven’t mentioned it because I’ve written about it before). A bit of advice here: Don’t try. If you have to merge data from multiple SaaS vendors, FTP the data to your own servers and perform the JOIN inside the firewall. Otherwise, network latency will eat your batch run alive.

This is how it looks to me, and telling you this doesn’t solve your problem, because just using these insights (assuming you agree with them) merely reinforces the potential for antagonism between you and the team you lead.

So don’t present any of this as a reason not to use SaaS vendors. Use it to lay out the engineering challenges the team needs to overcome if it wants to make the SaaS approach usable.

“There’s a lot I like about the idea … here’s what we need to overcome to make it work,” is a lot more conducive to building the team and your relationship with it than “Here’s why I don’t like the idea.”

And who knows? They just might figure out a way to make it work after all. If they do, please let me know.

– Bob

This story, “A little bit of cloud computing goes a long way,” was originally published at InfoWorld.com. Read more of Bob Lewis’s Advice Line blog on InfoWorld.com.