The Applicator

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.