Challenges to Integration

No matter which way you approach integration with legacy applications, you're certain to have more pain than fun. The older and less documented the systems are, the harder and more error-prone the integration becomes. The result is a classic "chicken and egg" syndrome, where throwing away the legacy data and functionality will kill the business, but staying with them will do the same. Trying to update the system will probably take longer than starting from scratch, but you can't throw away the old data. You come full circle.

As we talk about these issues we will find that integration problems fall into four main categories: documentation, interfacing, availability, and scalability. Now we will spend some time exploring these in detail.

Documentation

The unfortunate truth about legacy systems is that they're often poorly documented, leaving developers and businesses people alike reluctant to make changes. Everyone is afraid that doing so will break the system in some way. To add to the problem, the original developers or owners of these systems might not be willing to work with a newer team because of such trivial reasons as internal politics.

This reluctance or inability to change legacy systems is one of the primary reasons why integration is considered necessary in the first place. Without adequate documentation or legacy expert help, your integration projects are bound to face a miserable death.

Interfacing

Interfacing refers to the process of talking to and controlling legacy systems from another system. If you're lucky, your legacy systems were designed with integration in mind, as in the IBM Customer Information Control System (CICS), If so, interfacing should be relatively pain-free. This compatibility is hardly typical with many legacy systems, however, and getting an interface to function properly can be a daunting task.

Depending on whether the legacy system in question was designed with extensibility in mind, interfacing can be both time-consuming and expensive. Be sure to weigh the value of the interface against the effort required to accomplish it. You may find that a complete, perfect integration isn't worthwhile, but that a partial integration of only the most critical parts will suffice.

Availability

Web-based applications are generally expected to be available 24 hours a day, 7 days a week. Your legacy systems, however, might not have been developed with this lack of constraints in mind. Mainframe-based systems, as an example, are frequently designed with a periodic maintenance shutdown requirement. What will your application do when legacy systems are unavailable? How will it handle not being able to access the data it needs to function? How should it gracefully alert users of the situation?

These questions need to be answered when building your application, but the list of questions could be much longer when speaking of a specific application. You must know and understand all of the implications of the legacy system's availability, or at least as many as possible, when deciding how to use it. Any system you develop will inherit these restrictions.

Scalability

For many legacy-integration projects scalability might be the single biggest challenge. Most legacy systems are not designed to handle the large volume of traffic and real-time transactions that systems today must face. Legacy systems were often designed to support an elite few who had access to only a handful of machines. Many of these legacy systems were also batch-oriented and will not be able to handle online queries and transactions. For many applications, especially Web-based ones, being able to handle a large and unpredictable volume of online transactions is a requirement. Users of these applications will not wait days, hours, or even minutes for the systems to response. Including legacy resources in your chain of applications increases transaction time, thereby decreasing scalability.

These are some of the problems that will prevent a legacy system from scaling, and enhancing or improving one of these systems to function in today's environment is hard.



XML Programming
XML Programming Bible
ISBN: 0764538292
EAN: 2147483647
Year: 2002
Pages: 134

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net