Rule #6 of information technology marketing is that if you don’t have a new idea, coin a new word for an old idea.

Clearly, those promoting SaaS (Software as a Service) memorized Rule #6. Just as clearly, those who think it really is new have memory problems worse than Leonard Shelby, the protagonist in Memento.

Yes, yes, I know. SaaS is completely different from the ASP (Application Service Provider) business model that preceded it because SaaS applications are designed for web hosting where ASP applications weren’t. I know this, just as I know that ASPs were completely different from service bureaus that offered time-sharing access to systems back when COBOL was king because ASPs were engineered to deliver access through the Internet instead of private connections.

I also know the English spoken in the United Kingdom is completely different from what’s spoken here in the U.S.A., because they say “lift” and “lorry” where we say “elevator” and “truck.”

As an RIP (Recognized Industry Pundit — AAW? (Ain’t Acronyms Wonderful?)), I have a few questions about SaaS:

• Have they really solved the system integration problem? Blah, blah, web services. Blah, blah, blah SOAP (Simple Object Access Protocol — AAW). Yes, Salesforce.com has AppExchange. You’re still integrating across a high-latency, low-bandwidth interface compared to what you can engineer inside your firewall. More, the issue of SOA governance is gaining increasing attention. How do you plan to handle SOA governance when an SaaS vendor’s software is part of the mix?

• Whose release cycles are they? They are, of course, the SaaS vendor’s release cycles. That makes you vulnerable.If you issue a new release of in-house developed software or install an upgrade to a commercial application, you’ll regression test it to make sure it doesn’t break any existing functionality. Yes, I know the SaaS vendor’s APIs aren’t supposed to change, and the data formats are supposed to be completely stable. But let’s not forget everything we ever learned about testing and change control. These disciplines matter because software doesn’t always do what its authors intended it to do, not because it does.

• Is the touted advantage of being custom-engineered for web-based delivery truly an un-mixed blessing? From the perspective of engineering purity, of course it is. But anyone who looks at the subject solely from an engineering perspective is suffering from LSD (Leonard Shelby Dysfunction — see above; also AAW). Pandesic didn’t happen all that long ago.Pandesic, you’ll recall if you don’t suffer from LSD, was the SAP and Intel joint ASP venture. These two giant, reputable companies were willing to leave their customers in the lurch (see “Trend Overload“). What makes you think an SaaS vendor will treat you any better?By the way: SAP just announced that it’s entering the SaaS fray. To my knowledge every RIP (AAW) who has mentioned it has done so to enhance the SaaS model’s credibility. Not one has connected the dots between how shabbily SAP treated its Pandesic customers and its current plans. So you’re hearing it here first. Repeat after me: Fool me once, shame on you. Fool me twice …

  Make no mistake: If you build an SaaS vendor into your technical architecture and it goes belly up, you’re in even worse shape. Pandesic was built on SAP, so at least its customers were able to use the same software internally. SaaS software is custom, so you’d be dealing with a full conversion to an entirely different package. That’s much harder, and more expensive.

• Whose release cycles are they? Part II. Beyond the expense of regression testing and change control on their schedule, there’s the potentially much greater expense of business integration.Beyond any shadow of a doubt, every release contains features so cool they’re practically cryogenic. That’s nice. But businesses don’t “use software.” They integrate software into their business processes and practices to make themselves more effective. If the software changes, the business process or practice changes, or what’s the point?

  It very well might be that the new features are all entirely optional. It very well might be that whoever manages the process for your company will be nothing but delighted at the prospect of figuring out how to leverage the new capabilities every six months, and of training employees in the new-and-improved process twice each year.

  It very well might be, but it’s far from certain.

What is certain is that when you install software, configure it, and host it inside your firewall you have much more control over the release schedule. Software as a Service? Call it Software as Business Enabler (SABE).

AAW.