Breaking TraditionMany computing problems come down to one thing — legacy applicationsBy Joe Celko Programmers always talk about legacy systems, but I've never heard them clearly defined. The vague consensus is that a legacy application has been with the enterprise longer than the programmers who are now maintaining it, lacks good documentation, and has untouchable code. But I don't think that loose definition really works. When I answer SQL questions on newsgroups, at least a third of the time the programming problem is a direct result of the bad schema design in the database. I will then suggest that if the programmers would normalize the schema or stop using some proprietary feature in that particular SQL product, they wouldn't have these problems. The certain reply is that they are working on a legacy system and can't change anything in it. (Well, except for the part that they were working on when they found a problem so difficult that they had to go to a newsgroup for help.) AN AXE TO GRINDThis problem is like the story of the axe that had been in a farm family for more than 200 years. Well, the head had been replaced a few times and so had the handle, but it was the same axe. Because it was a legacy from the great-great-great-grandfather, it couldn't be sold or thrown away even when the family bought a chainsaw. Is the accumulated effect of patching over time what makes the documentation for a legacy system either a mess or nonexistent? The argument often goes that because programmers don't understand the system, they don't dare change it — and it continues on as a legacy system. But the horrible fact is new systems can and do have a dearth of documentation, too. They were "born" that way. The one characteristic I can see in what people call a legacy system is that it's monolithic. You can't change the code because it's one big solid block and not a lot of little Lego bricks. It's not integrated with anything else. A LEGACY FACELIFTBut this is a matter of programming and not age. Many of the ERP packages come written to perform certain business functions one way. If that matches your company's business rules, then you're fine. If it doesn't, then you can't pull out its modules, write new code, change the database, and expect the rest of the system to keep running. What you can do is extract the raw data from the package's database, write your own routines with your own business rules, then put the new data back into the old schema. At this point, you are free to transform the data into whatever format you wish. And that data format might be the one used in another package. Suddenly, you look around and realize that 60 to 70 percent of your computing power is moving data, not computing with that data. A December 2001 study from the Hurwitz Group found that only 10 percent of enterprises have fully integrated their most mission-critical business processes. No wonder there are all these little islands of untouchable legacy systems. E-businesses no longer make a distinction between discrete internal or external processes. It is just a business, and it's better to have things seamlessly flow from external to internal processes. The kicker is that there is a significant lack of awareness among most enterprises about which tools are currently available. The result is that they continue using older tools with limited functionality. I am still not sure what a legacy system really is, but I think I might be closer to the answer. Joe Celko [71062.1056@compuserve.com] is an independent consultant in Austin, Texas and the author of Joe Celko's SQL for Smarties: Advanced SQL Programming (Morgan Kaufmann Publishers, 1999). |
 |
Most Popular This Week
IE Weekly Newsletter
Subscribe to the newsletter
| |
|