How to avoid short-lifespan enterprise applications?

Question

A while ago another question referred to the (possibly urban tale) statistic that

... the average lifespan of software is about 3 years

At the time I came up with the following reasons (and I'm sure there are more possibly better ones):

1. A new major system (ERP, CRM, etc.) is implemented and it has an "integrated" module to replace the old app.

2. Same, but no integrated app - but the existing app is not adaptable (the people left, technology has changed, current IT policies have changed, users don't like the existing app.)

3. The company you acquired the basic app from, to customize it for your needs has disappeared.

4. Or you don't get along well with them any more.

5. The technology for the existing app is "obsolete" (according to the framework vendor/Microsoft/consultant/industry expert/new IT manager who has management's ear.)

6. "We're phasing out (Windows 95/Windows 98/Windows 2000/Windows XP/NT) and we need matching technology in our apps".

7. "We've learned a lot from (App Version n) and we'll do a lot better the second/third/fourth/n+1th time."

8. Job justification for developers/IT manager/Division VP/consulting company.

9. The users hate it.

10. We've merged/acquired a competitor/been acquired by a competitor and theirs is better.

Some of these are unavoidable (e.g. your company gets bought), but overall this is surely smething that needs to be avoided. Does your organization intentionally fight this syndrome? What effective strategies would you recommend?

Answer 1

That's why an application needs to be easy to expand, and you should be able to easily add-in all the buzzwords.

If you have a solid base code, most of the buzzwords are related to the UI (Vista Controls, Ajax, .net, ASP.net 3.5)...

You could be running COBOL in the back-end ( I wouldn't).

1. A new major system is implemented - There's nothing you can do.
2. current IT policies have changed, - The app should be adaptable.
3. users don't like/hate the existing app - why? cosmetic changes in the UI can fix this most of the time.
4. The company you acquired the basic app from, to customize it for your needs has disappeared. - I wouldn't do that, I'd prefer to write it myself.
5. The technology for the existing app is "obsolete" (according to the framework vendor/Microsoft/consultant/industry expert/new IT manager who has management's ear.) - same as the above, if the back-end is solid, you should follow these in the front-end.
6. "We're phasing out (Windows 95/Windows 98/Windows 2000/Windows XP/NT) and we need matching technology in our apps". - a simple compatibility test and minor UI elements solve this.

I'll also say that this is different when you compare in-house to commercial apps, if you're doing an in-house app, change guarantees your job (if you know what you're doing). If you're doing a commercial app, change is an opportunity to make more money, new features would get you upgrades from existing clients and new clients who are looking for the buzzwords, these buzzword could become your advantage when compared to a competitor.

Answer 2

• Continuous improvement - add useful features at regular intervals
• No show-stopping bugs in new versions - testing, testing, testing...
• be nice to your clients and treat them with respect (most users really don't want to change their ERPs every three years so if you have a good realtions with them they'll be on your side)
• Stay current with new technologies and integrate them in your application when needed

Answer 3

The average lifetime of software I write at the moment is probably a few days. (I write a lot of scripts, so I might be an aberration. ;-) But the core system I work with is probably 15 to 20 years old now. The underlying OS is about 30 years old. There is nothing inherently wrong with either old or young software. In fact, software ages best when it's possible to adapt it to new uses.

Having layers of abstraction between functional parts make it easier to replace functionality in a system. For instance, we've gone through several different tape libraries on our system and now we are considering going to disk archives in the future. Since the "archive" portion of our system sits behind an abstraction layer, we can replace it fairly easily without replacing the rest of the system.

When possible, it's also best to use standard parts. That way, if you run into some limitation, it's likely others will have the same problems and more likely someone will come up with a fix.

Answer 4

When gathering requirements and someone says "Situation X will always be the case, no exceptions", make it configurable. It will always change, no exceptions.

Answer 5

Most companies don't make it for 5 years. Their software implementations wouldn't be expected to last as long.