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.
Why Pay Maintenance on Enterprise Applications?
May 28, 2009
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.
Problems with Cloud Services I: RIM and XO
April 13, 2009
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.
The Applicator 