Rich -On Feb 29, 2012, at 2:02 PM, Rich Cooper wrote: My advice to anyone working on programs that were written thirty years ago is to find another job. The technology is outdated, the tools have become much, much better, languages are more expressive, and subsystems can be licensed far more effectively now. My advice to managers who have a thirty year old software system of significant size is to muddle along as best they can while building an entirely new replacement using modern technology.
Unfortunately that's really not an option.
This is precisely why legacy systems maintenance is so important.
Those 30+ year old systems are in place. Replacement efforts tend not to be successful.
Regardless of all the pejoratives you want to throw at these systems, replacing them has proved to be very difficult for a long list of reasons. I've got plenty of anecdotes: a company with 28 DBMS engines (that's ENGINES, not databases), EDS went into the Navy expecting 5,000 systems & found 100,000.
"More expressive languages"—I'm struggling to learn Objective-C—often bring with them a steep learning curve.
The biggest challenge of all: managers are rewarded for SHORT TERM RESULTS. Efforts that take 5-10 years don't even get to the table. Do you know anyone willing/able to sign off on a 10 year effort to replace a critical system(s) with SAP?
If ontologies are useful, they should be able to examine an application & distill the 1,000s/10,000s of terms down to very short candidate lists. I have a fairly large banking system that is 3,000 years old—this is Letters of Credit—and it has a mere 360 unique terms. I could probably further compress that by splitting it into business terms & system adhesion terms.
Can ontologies help discover that reality in all the fog? Quickly? ___________________ David Eddy
781-455-0949 |