All Posts in Technology

|In: Industry Commentary|Last Updated:

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.

Comments

|In: Leadership|Last Updated:

What if we called it herbal IQ juice?

Highly organic friends of mine routinely disparage my coffee drinking, telling me how unhealthy it is to quaff vast quantities of the caffeine and other chemicals it contains. But if a health food store sold the same stuff as a natural infusion that increases alertness, they’d be recommending it to me, don’t you think?

How you communicate a concept has a lot to do with who accepts it and who rejects it. Which gets us to the issue raised last week — what causes management DRIVEL (Direct Reduction In the Value of Engineering Likelihoods) in response to the recommendations of their technical experts.

It’s time for equal time: The root cause isn’t always management ignorance, stupidity or short-sightedness. Sometimes, it’s that when explained by engineers, Benefit Language is Awfully Thin, Horribly Elucidated, or Ridiculous. (BLATHER). Engineering BLATHER is a major cause of management DRIVEL.

Think back to the early days of the World Wide Web. Marketeers put up websites with blithe disregard for engineering discipline. Getting new pages up quickly trumped such minor considerations as testing, server reliability, or security.

I know from first-hand experience that many IT professionals sat on the sidelines, sulking at such disrespect for quality engineering. They presented their BLATHER to the marketing director, and the marketing director ignored them.

Marketing directors might not know much about engineering, but they do understand that in their world, when faced with the old quicker/cheaper/better trade-off, quicker usually comes first. They viewed their discussions with IT the way a film director might react to recommendations for professional plumbing and electrical work when building a set. It’s just a bunch of BLATHER.

Let’s be honest with ourselves. Bullheadedness is something of an occupational hazard among professional engineers. Many ignore Louis Sullivan’s famous dictum that form follows function, instead considering quality engineering to be an absolute characteristic with intrinsic value. If anyone challenges The Rules, engineers of this persuasion commiserate with each other regarding the sad ignorance of the unconverted heathen, never once considering the possibility that they’re applying their Rules to situations for which they aren’t suited.

Even among engineers who understand that Hollywood sets call for different engineering standards from factories, factories from office buildings and office buildings from domiciles, many still rely on BLATHER to explain what’s required for a project to succeed. They find to their dismay that it’s rarely convincing.

Which brings us to an inviolable rule of communication: At least one party must learn the perspective and vocabulary of the other.

Sophisticated managers, willing to take the time to learn how engineers think and speak, are able to penetrate engineering BLATHER to understand why the recommendations of the engineers matter. They’re the minority. Luckily, the perspective and vocabulary of management are sufficiently simple that engineers who want to can learn them in … well, in what’s left of this column.

All you gotta do is connect your engineering requirements to one of the “Big Four” management evaluation criteria: Increased revenue, decreased cost, reduced risk, and career impact.

Take an example: Microsoft Access and why it’s not the right tool for building production-grade IT systems. Many IT professionals will tell a business manager who’s interested in using it that it’s just a toy, inappropriate for a production system — trust me.

Faced with that impenetrable BLATHER, the business manager contracts development of the system … in Access … to an outside contractor who builds the system at a tenth the cost of IT’s estimate.

An IT professional who’s as interested in being persuasive as being right will take a different approach: “Access is suitable for small or prototype systems only. If this project succeeds, too many users will be hitting the database, which means the system will slow to a crawl. You’ll want us to add more features and functionality, which means the system will slow even more. And the database will grow, which means … yes, that the system will get even slower. That means that instead of increasing productivity, you’ll have a lot of employees twiddling their thumbs waiting for the software to respond, which will cost you a lot more than you’ll save by building the system in Access. Even worse, Access databases become fragile when they get too big, which means that if you’re lucky we’ll have to take the system offline fairly frequently to repair the database, and if you’re unlucky you’ll lose data.”

No matter how much you avoiding engineering BLATHER, you won’t entirely eliminate management DRIVEL. Nothing will.

But at least you won’t cause it to increase. And that’s a worthy goal.

Comments