Off Maintenance? What’s Your Application Strategy Going Forward?

June 2, 2009

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.

Advertisements

One Response to “Off Maintenance? What’s Your Application Strategy Going Forward?”

  1. B Says:

    Hi David, I’ve read these points with interest as we are actually some way down this road with our front office system. Believe it or not we are running a version 6 major releases behind the current one and a very early patch at that. The system will be 10 years old next year and, despite being customised very heavily over the years, has had no significant downtime in the last few years. It just keeps chugging along.

    Due to the extremely arrogant manner of the vendor in the original implementation and a relatively small degree of change within our front office, we have been off maintenance for over 5 years now and have saved many millions both through not having to pay this money but equally through avoiding the cost and expense of unnecessary upgrades.

    It is very much an option in this day and age but I think you have also hit on a key point where we have failed which is to incorporate this into your long term apps strategy. Realistically our application is approaching the end of it’s useful life due to business growth and change and we will have to replace it in the near future. We do have to approach the replacement as a completely new project even if we go with the latest version of the original vendors software but the existing platforms stability (and cheapness!) has seen it constantly being relegated in priority terms and this is starting to cause more and more problems both for the business users and IT.

    If/when it is replaced we certainly won’t assume that we will stay on maintenance for the life of the application if they cannot clearly articulate the value in this, and we will be closely looking at third party and cloud-based alternatives to the on-premise option.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: