Vinnie Mirchandani frequently rails against maintenance fees in his Deal Architect blog, quite correctly in my view. As apps get older, the ecosystem becomes more robust, the number of people available to make the things work increases, and the underlying technology gets better, prices should go down. That they don’t is a testimony to the chutzpah of the application vendors and the, er, timidity of the customers, nothing more.

But let’s say, Vinnie, that you know this and you’re not particularly craven, but you need these guys. What do you do? Or let’s say that you’re just buying something they’re offering, because it makes sense. What do you do? Or let’s say that you believe those silly pundits and you’ve decided to go off maintenance. What do you do?

As I said in an earlier post, you still need an application strategy. The question is really, “What should that strategy look like?”

In that earlier post, I suggested that you should favor cloud applications, because they reduce the invisible, but very real long-term infrastructure costs. You should think Google Apps and Salesforce and developing on Amazon (but not on Intuit’s QuickBase, no matter what you do).

But this isn’t in itself a strategy, it’s just a guideline. So let me add another such guideline.

Think small.

Do you remember back when Jerry Brown was governor of California and was talking about something he called, “Appropriate Technology.” Appropriate technology was small stuff, which worked, which didn’t cost too much, and which was suited to a small, local problem at hand.

Let me give you an example that I remember from the time. Our local, San Diego power company wanted to build a plant in the desert, basically to deal with peak power demand. This was a big technology solution. Perhaps emboldened by Governor Moonbeam, the appropriate technology people proposed a combination of cogeneration and peak usage pricing. Miracle of miracles, they one. Why? Well, I can assure you it wasn’t because San Diego County had gone blue. It was because everybody could see the point of not having to pay for concrete and transmission lines, when they didn’t have to.

Oh, gosh, am I talking about best-in-breed apps, heterogeneous computing environments, multiple vendors, nightmarish integration costs, etc., etc., all the things we were trying to get out from underneath when we jumped onto the big app bandwagon?

Yup, yup, yup. That’s what I’m saying. In this day and age, you’re better off figuring out small, local solutions to specific problems–and accepting the costs associated with that–than you are buying a large, global solution, that supposedly offers economies of scale, but never delivers them.

If you adopt this strategy, you think (or at least you entertain the possibility) that a small, light call center/knowledge management app that deflects 10% of the time-wasting calls and can go in tomorrow, SaaS, might do more for you than the global call-center app that is designed to automate your interaction with most of your customers, costs jillions, and will take so long to install that none of us will ever be there to see what happened–even though the large app is supplied by your primary IT supplier and will become part of your global application footprint (the one you pay all that maintenance for).

I know it’s a radical notion. But that’s the idea. Think small. Look for small improvements. Buy small apps to make the small improvements. Don’t buy more than you need; assume that light apps that do less are the way to go.

Given the cost structure in place today, you’ll not only do more, faster; you’ll save money.

Why? Well, when you cut through all the nonsense, it’s the same reason I pick up a wrench rather than call the plumber. It doesn’t require that much. The job gets done. And there’s no reason to pay any more than I have to.

Four-Five Years

March 31, 2009

Within the tiny world of SaaS executives, there’s a little-known rule of thumb. I call it the Four-Five Years Rule. The rule is this. “When comparing the cost of SaaS offerings against an equivalent perpetual license offering, the break-even point comes in four-five years.” That is, when you add up the total cost of leasing a SaaS offering and the total cost of a perpetual license offering, the latter including hardware, the software license, and maintenance, and even the cost of money, the SaaS offering is cheaper for four years-plus; after five years, you’ve spent less on the perpetual license offering.

Did you know that? Bet you didn’t.

So is that an argument for SaaS, or is it an argument for perpetual license? After all, most installations last longer than 5 years. So maybe you should bite the bullet and pay up front, right?

No. You see, there’s a big, big difference between the two at the break-even point. With a perpetual license application, the application you’ll have is four-five years old. (You see, I’m not including the cost of upgrades.) But with a SaaS application, the application you’ll have is brand new and up-to-date.

It’s sort of an inversion of the old automobile lease-vs-buy conundrum. At the three-year breakeven point, if you buy you have a car, but if you lease, you have an empty parking space. With software, if you lease, your installation stays new. If you don’t, it gets old.

It’s also an inversion of the standard idea about SaaS, that it’s cheaper, but you get less. Not at all, after five years, it’s more expensive, but maybe worth it, because you’ve got a superior product, one that’s been kept up to date.

Not necessarily worth it, mind you. If you don’t need all the stuff they put in to keep the software new, or if you need to customize, you’re definitely better off with perpetual license. A lot of it depends on what you think the useful life of the old software will be.

One last argument for perpetual license, of course. If you do think the old software will have a long useful life, you can plan to save a boodle by going off maintenance sometime after those five years are out. If you do that, perpetual license can be way cheaper.