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.

Advertisements

Chiseling On-Demand

June 15, 2009

You know the old joke, “How can you tell whether a software salesperson is lying?”

What about when it’s a “No-software salesperson?”

The question came up the other day when one of the people in the office went off to Intuit’s road show for its on-demand database. (Intuit is putting Quickbase on line, promoting it as the cloud’s answer to Access, and the road show was for people who might develop on it, using a Flex-based front end.)

This person came back less than wowed, of course; what do you expect, it’s Intuit. But the quality of the product seemed to me to be beside the point. No matter how good or bad it is, I argued, you would have to be absolutely cracked to have anything to do with it.

Why? Because the way Intuit behaves itself in the on-premise world makes them a non-starter in the on-demand world.

Believe me, I know whereof I speak. I am a heavy user of Intuit products: TurboTax for 10 years or so, QuickBooks for four, Quicken, now, for two. I have thus had more exposure than I would ever, ever like to have to Intuit’s chiseling ways: the design that plumps unerringly for the cheap and stupid way of doing things, the support that has at times left me screaming at the telephone, the innumerable ways they have made my life harder because they only want to deliver the absolute minimum, the endlessly inventive efforts to extract an extra $5.00 or $20.00 from me.

I use the products, despite all this. But only because, over the years, I have figured out how to keep the chiseling costs down to what I think is an acceptable minimum.

Mind you, sometimes they nail me, even so. This year, it happened twice. This year, for instance, they decided de-support QuickBooks 2006 Professional Edition. “Desupport, I thought? I don’t get any support from them anyway.” Turns out, of course, it was a way to get me to plunk down another $300 for the latest edition. Didn’t work; I finally figured out that there was no reason to pay another $300 for software that I already owned. But it did cost me more than a few hours to figure that out. And it burned me when I figured out that what they were doing, in order to make me want to upgrade, was taking away their QuickBooks e-mail invoicing service. $100/year to send out invoices? Give me a break.

But they weren’t through with me of course. This year, I saw the most inventive piece of chicanery I’ve seen in a long, long line. Instead of sending me a check for the TurboTax rebate, they sent me a debit card with a $10 credit. This turned out to be much more fiendish than you might think. First of all, even though it says debit card on the card, it’s actually a credit card, so if you say, “Debit,” to the cashier, it’s refused, something I find embarrassing. Second of all, even after you get on to that dodge, it’s a lot of work just to use it. Either you have to come up with an item that costs exactly $10, or you have to split the bill between two credit cards–also embarrassing. So what did I do? I finally bought a $7 item, and I guess I’m going to let them have the remaining $3.

So what does this have to do with cloud computing? Well, let’s put it simply. If you have enterprise application software, and you’ve bought a perpetual license, you have a defense against at least some of the chicanery and chiseling that seems to be built into relationships with software vendors. You can stop dealing with them and still use the software. But with a cloud computing vendor, you don’t have that defense. So you’re much, much more vulnerable.

My supplier of enterprise application software happens to be Intuit, and with Intuit, I simply don’t allow myself to become that vulnerable. I never use the Intuit Quickbase product or the On-Demand version of Quicken or QuickBooks; I don’t even use the on-demand TurboTax backups. Why? I have been victimized by Intuit’s sharp practices many times, and I don’t want to give them an even bigger and more vulnerable target.

Now I don’t blame Intuit. They invented a business model that really worked for them and apparently works for millions of customers–a kind of RyanAir for software, where you provide the maximum amount of irritation and inconvenience possible in return for a rock-bottom price. But this is not a business model, I think, that consumers should accept when it comes to cloud-based applications. There’s just too much risk that a Ryan Air-like application company will ask you in mid-flight to chip in a little bit more so they can get you back down on the ground.

If it were just Intuit, of course, I wouldn’t burden you with my ranting. But it seems to me that Intuit is not the only company that came of age in an era when you delivered software to the premises and discovered that you can make a fair amount of money in that context by overpromising, underdelivering, and making sure that you have your customer’s wallet firmly in your gunsights at every moment. I hate to say it, but there are much bigger companies that deliver much bigger accounting software that have the same mind-set. So if it’s unwise for consumers to trust Intuit’s approach to business when it comes to cloud applications, isn’t it unwise for consumers to trust the other guys?

Now wait a minute, Leo or Larry might say, aren’t you tarring perfectly reputable, upright, leading companies with a brush that should be reserved for Intuit? Well, I dunno. I don’t own your software. You tell me, L&L. I know that Intuit has provided me with support that was completely inadequate and left me genuinely vulnerable as a result; has your enterprise software company done that? I know that Intuit has misled me about what’s in upgrades or in more expensive editions and cost me a lot of time and money as a result; has your enterprise software company done that? I know that Intuit has tried to charge me for things that I thought were included in the original deal and has raised rates on me without providing anything to me in return; has your enterprise application done that? And I know that Intuit designs software in a way that shifts a lot of costs onto me, even though it would often be very simple for them to avoid doing this. Does your enterprise application company do that?

If the answer is, “Yes,” to any of those questions, what’s going to stop you from doing this to your customer again, when your customer buys your cloud-based apps?

Maybe there’s an answer. But until there is one, my recommendation for customers of companies that do this would be to avoid their cloud-based applications for the same reason I would run, not walk away from Intuit’s.

So how do you know if your No-software salesman is lying? Well, I guess you don’t. But if he used to work as a software salesman, shouldn’t you at least check what he says?

Cloud Confusing

June 5, 2009

This is one of what I hope is a long series of posts on what’s wrong with cloud computing. (The more cloud computing grows, the more things there will be wrong with it.)

OK, so this morning I get an e-mail from Xactly, a sales compensation software company closely allied with Salesforce. It’s a hosted, oops, cloud application, a fixture on the AppExchange, which at least theoretically lets salespeople who use Salesforce figure out what their compensation is going to be if they ever get one of those sales.

Steve Cakebread, part owner of Cakebread Cellars and, oh yes, for many years CFO at Salesforce is giving a seminar on how to sell to the CFO. The seminar is sponsored by Xactly of which, not coincidentally, Cakebread is now the CFO.

The wine is quite good. I’ve had it at many of those lavish events for analysts that Salesforce used to sponsor back in the days now gone. But of course it was before noon when I got this e-mail, so I didn’t think too much about the wine.

So I signed up, or tried to. You see, while Xactly may be on the AppExchange, they don’t use Force.com as a platform, they have their own product which is hosted by OpSource, another long-time Salesforce partner and AppExchange stalwart that has a particular appeal to AppExchange partners because they help people through the process of joining the AppExchange.

The e-mail comes from Xactly, but actually Xactly is using the events software from OpSource, so when you register, you register at a site with an OpSource URL.

So when you get to the registration site, you can see labels, like Name, E-mail, etc., but you can’t actually see any fields to put your name in. This is probably due to the fact that OpSource (or whoever wrote this registration page) actually doesn’t believe in providing products that work correctly on Firefox, another cloud computing provider.

Where is that wine?

To register, I have to find the fields by hitting the Submit button, which gives me an error message, saying I haven’t filled out a field, and then I can kind of guess where to put the cursor, and at the end, my name is David Dobrin Dobrin, because I put David Dobrin in what I thought was the Name field, but was actually the First Name field and then had to poke my way around until I could find the Last Name field and put my last name in again.

Is it noon, yet?

So I’m registered, yay, but I can’t actually remember when it is, so there’s a little button that says, “If you’d like to sign up with Adobe Connect, you’ll get an e-mail with an item for your Outlook calendar.” I cringe a little because Outlook calendar items don’t integrate very well with the Mail app from Apple, but OK. So I hit the button. I am now hooked up with Adobe Connect (although it’s still an OpSource URL), and again, I am asked for my registration information. So do I have to register again or not? You tell me. I don’t know.

Except that there’s another button that says, “If you’ve already registered with us, click here.” Now who is “Us?” OpSource? Adobe Connect? Xactly? Salesforce? Cakebread Cellars? I’m assuming “us” means “the seminar you just signed up for, dummy,” so I click the button. Up come a username and password field. For whom? OpSource? Adobe? Crud, I wonder if my old username and password for that meeting software that Adobe bought years ago still works. What was it? I can’t remember.

Guys. Give me a break. If I want to sign up for your seminar, I don’t want to have to establish/remember relationships with three other cloud computing companies. The only other company I even want to know about is Cakebread Cellars. If you don’t actually believe in, want to participate in, or know anything about universal identifiers as a necessary lubricant in the cloud, then at least have the good taste not to inflict all your relationships on me.

In cloud computing, you always do a lot of function shifting onto your partners. But if that simply becomes cost-shifting onto your customer, you and cloud computing have failed.

And when that happens, I have a ready alternative. Instead of dealing with Cakebread CFO, I deal with Cakebread Cellars. Have some wine.

Let’s say you go off maintenance. (I know, I know, it’s unthinkable. But there’s no harm in a little noodling, is there?)

So you go off maintenance. What consequences does that have for your application strategy?

Don’t tell me you don’t need one any more. You still need a strategy. True, you’re letting your primary back-office application lie dormant. Unfortunately, though, even today your current application doesn’t work perfectly. And, as time marches on, your business will change, your work will change, new kinds of work will come in–and you’ll need to deal with it.

I don’t know of any analyst who has actually addressed this issue. So there isn’t a canon of accepted practice. You’re kind of on your own.

But I think there are some principles you can follow, so let me suggest them. It might help. Broadly speaking, they are as follows:

* Don’t go backwards

* Embrace heterogeneity

Going backwards is dropping back to an era when IT tasks or business tasks were done on isolated, often custom-built applications. If you need new functionality, and you’re not going to get it from your now moribund application, the obvious thing to do is build it yourself, just as you used to do.

Don’t. The reason we bought commercial applications was that doing it yourself cost too much. The cost of maintenance for the home-grown stuff and the unsatisfactory performance of what you got, often due to limitations on access, outweighed the benefits of having a bespoke application. If you ignore this lesson, you’ll repeat the same mistake. If you learn from it, on the other hand…

And heterogeneity? Well, the other reason we embraced commercial applications was that heterogeneity was too expensive. Yes, you got a best-in-breed application, one that was well-suited to the business.But the cost of integration (and other maintenance costs) was simply too high. You were better off using the [Fill in blank] stuff that your platform vendor foisted on you.

So, shouldn’t you learn from this and go back to the platform vendor with your tail between your legs? Not necessarily. You see, the cost of best in breed has gone down a lot, and the difficulty of integration is less. What’s more, the delta between what best in breed does and what the platform vendors do remains very high. (i2 or Manugistics works much better than APO or Demantra in many cases.)

Bearing these principles in mind, how do you approach the problem of adding to or extending what you’ve got, when you can no longer ask the software vendor for help? Here are some suggestions.

1. Always ask yourself, “Why not the cloud?” If you’re thinking of buying a best-in-breed application, can it be a cloud-based application? If (horrors), you’re building something yourself, can you put it in the cloud? Why the cloud? Because a cloud-based application changes the economics, be it an application you build yourself or a new, best-in-breed application.

Take a simple, simple example to show you what I mean. Assume that you’ve gone off maintenance, and you want to establish a new discounting system for large customers, which involves basing the discount on the volume of orders, frequency of orders, credit history, and credit rating. Let’s assume that customization is unreasonable, partly because of the maintenance issue.

The temptation is to put the data on a spreadsheet, roll in the data once a week, have it do the calculation, and then and change the discount table. Fine. But wait a minute. Why not the cloud? Rather than putting it on a spreadsheet, which will be locked on somebody’s computer for the rest of time, why not put it on Google Apps?

It may not seem like it, but the costs of storage and maintenance for that mission-critical spreadsheet are significant. So are the costs of making the data easily accessible and securely available to all the people (and systems) involved. So are the costs of getting updates from public data sources out in the cloud. So are the costs of having the spreadsheet “belong” to one person.

Get rid of all those costs, in one swell foop, and make it easy to use other public data sources as you refine your discounting. Put it in the cloud.

2. Try to do less for your application customer. No, don’t recoil in horror. Ask yourself what the right strategy is going forward. With your old platform strategy, which you’re now abandoning, you always wrote for the ages. Be it a report, a custom app, or an app extension, you wanted it to be robust and highly satisfying to the user, doing everything that the user wants. But if you’re not building for the ages, you want to rethink this. There are many situations where quick and dirty is superior, where even the users would rather have something fast that works more or less. You’re in an age of limited resources; don’t go backwards to the time when you were expected to achieve perfection.

3. Tolerate application islands. The idea of your platform, remember, was that eventually everything would be on one system. Great idea. More work done by the platform would mean fewer systems to manage, more consistent data, better access, etc. Well, that idea is over with; why not look to make the best of the freedom this gives you. Lock down the mission-critical data and functions, sure. But aren’t there areas where people want to use best-in-breed apps, iPhone apps, social networking apps–am I scaring you, yet?–and really, at the end of the day, you’ll make their computing environment better if you let them? Remember, if you’re off maintenance, the new work still needs to get done. Why not be open to finding the best way of doing it?

I could go on, but hey, I know that I already write the longest blogs in the known universe. Comments (and more questions) are welcome. It’s a fruitful and interesting topic. It needs more discussion.

A client asked me the title question recently, and my answer was just a shrug of the shoulders. The answer is, “They probably shouldn’t.”

Yes, it’s a little more complicated than that. Maintenance on enterprise applications may be worth it to some customers, just as an extended warranty plan might well be worth it to some buyers of appliances, automobiles, or electronic, because they they get some comfort in knowing that they can do something if it breaks. It’s also worth it–absolutely 100% worth it–if your installation is in its early stages or incomplete, that is, you’re planning on buying more software from the company or you’re certain that you will need to maintain an aggressive updating policy.

But for most customers of most enterprise applications, it seems to me that paying a maintenance bill is in some ways akin to putting down your money in a three-card monte game. The money is gone. And it is more than a little unlikely that you’ll get any return from it.

Have I ever done this? Well, I’ve avoided three-card monte. But there was a period in my life when I paid for a health club membership that I wasn’t using. I kept on thinking, “Oh, I’ll go there next week,” or “I don’t want to have to pay the initiation fee,” or “My doctor told me to get more exercise,” and so I paid.

But really, it was just that I couldn’t face the facts. I hated that health club; I hated the pool and the locker room and the crowding. I hated the way they were gouging me. And I hated having to admit all this to myself. So I paid.
I didn’t use my membership, but I paid.

So is that why most people pay maintenance. I think so. At the moment of payment, it’s easier to write a check than it is to face facts, so they write a check.

Now there is an obvious counterargument to this. It goes like this. Paying maintenance isn’t like paying for a health club membership; it’s like paying for insurance. True, with insurance, you pay and you pay and there’s little visible benefit. But that’s the idea. Frankly, you ought to be happier to pay and not get much visible benefit than to pick up the phone and call the insurance agent.

This is certainly the argument that the CFO hears when he calls up a CIO and says, “Can’t we do something about the 2 million a year we pay to $AP (that is, any of the middle-aged apps vendors)?” The CIO says, “There’s nothing we can do. It’s an insurance policy. We have to pay. What happens if our system goes down?”

Most CFOs seem to find this compelling. But they shouldn’t. Come on. They’ve been to business school. There is a point, obviously, when it’s not worthwhile to pay insurance. To see what that point is, imagine that you lived in a normal, middle-class neighborhood where there hadn’t been a serious house fire in twenty years. Would you carry insurance if the insurance cost was 1/5 the cost of rebuilding the house? You shouldn’t. What about 1/10? Nah. What about 1/50? Well, maybe, but probably not. 1/100? Nope. Normal insurance for this kind of situation shouldn’t be much more than 1/200, and that should cover a lot of other things besides fire replacement.

So the CIO is right only if the odds of failure are high or the cost of maintenance is low. As for the odds of failure being high, I don’t think any CIO should be basing the argument on this. If the odds of catastrophic failure are high, even after operating the system for years, maybe you need a new CIO. As for the cost of maintenance being low? Well, they’re not. They’re a a little more than 1/5 (of the software costs). So you could just stop paying maintenance and after five years, you’d have enough money to buy a brand new package, with money left over to pay the integrators. Yes, the integration and hardware costs would add on a fair amount. But to pay those, you could just coast for a few more years. And remember, when you’re finished, you’re getting a new system, one that is now ten years more advanced than the system you bought.

So which should you do? Don’t pay and save for a new system that will work better. Or pay for insurance that you don’t or shouldn’t need.

So what’s the answer? Don’t pay. It’s really very simple.

Talk to the typical SaaS executive about the complexities of customer service in Cloudland, and they give you a blank stare. What’s the problem. We provide our service. We guarantee it. We do a better job than

Well, yes. But that’s not all. When you’re getting cloud services, the services are often coming from multiple providers. Each of them can think they’re doing a good job or the right job. But even so, delivery can fail. And when that happens, it’s a nightmare for the customer. A nightmare.

Here’s a simple example. I have a Blackberry Pearl. My web site and domain name are hosted by XO. Two SaaS providers. I get my Blackberry e-mail from XO, which forwards it to the Blackberry domain name (tmo.xxx.com).

All of a sudden, this weekend, I started lots and lots of new spam–you know, the usual, sex stuff, plus a lot of spam with a Facebook return address, etc., etc., stuff that had been filtered. The new spam appears on both my Blackberry and in the e-mail delivered directly to my POP3 Mail account on my Mac. But much more new spam appears on my Blackberry.

Obviously, something happened to one or more of the spam filters that are provided to me. I know of at least two of these filters: one at XO and one on my Mac. Is there another one at RIM? Who knows.

I’d like it to stop, but I don’t have the time to troubleshoot this problem. Did XO change its forwarding policy? Did RIM install a new filter and screw up? Who knows.

If I just had one provider, I’d have some chance of solving it. But when I have two, I just have to sit and wait. The worst of it is, it might be the case that neither provider will ever realize that there’s a problem.

I wonder if the iPhone has a spam filter on it?

The point? Well, cloud service providers need to start thinking about this–and taking responsibility for the actual delivery of services, not just for making those services available.