12.1 Legacy Fortresses

12.1 Legacy Fortresses

Legacy fortresses wrap existing prefortress systems and allow them to work within the context of an enterprise fortress architecture.

There are arguments in favor of keeping existing systems and arguments in favor of discarding them. On the keep side, existing systems usually work and often represent huge investments. On the discard side, existing systems are often difficult or impossible to modify, they often run on expensive mainframe configurations, and they are sometimes designed in ways that make them rather hostile to enterprise-level collaboration.

I usually take a conservative approach to legacy systems. If the system can be wrapped relatively easily in a legacy fortress archi tecture, then I recommend this approach. Once the legacy system is snuggly wrapped, it can always be reimplemented, should a rewrite prove justifiable.

Some legacy systems can be wrapped easily; others cannot. The deciding factor is usually whether the legacy application follows a three-tier architecture or a client “server architecture. Three- tier architectures usually wrap well. Client “server architectures, with their intermingling of user interface and business logic, are usually difficult to wrap.

A typical three-tier application is shown in Figure 12.1. It has all of the following characteristics:

• The user interface is cleanly separated from the business logic.

• The system can be configured so that the user interface can be run on a machine different from the one that runs the business logic, and both can run on machines different from the one that stores data.

• System resources, especially database connections, are owned exclusively by the business logic. No system resources are owned, controlled, or managed by the user interface logic.

Figure 12.1. A Three-Tier Application

If all of these conditions are true, your legacy system can rightfully call itself a three-tier architecture and you can probably wrap it comfortably into a legacy software fortress. If not, you still may be able to accomplish wrapping, but the results will be problematic and the technical aspects more daunting. In this discussion I will deal only with systems that are already three-tier systems.

A three-tier system already has a well-defined plan for communi cation between the presentation tier and the business tier. If it is a Microsoft system, it is probably using ASP or ASP.NET on the presentation tier, COM+ on the middle tier, and DCOM as the linkage between the two. If it is an older Unix application, the middle tier may be a Tuxedo application. If it is an older IBM application, the middle tier is probably running CICS. All of these technologies have well-defined communications channels for moving information between the presentation and middle tiers.

To wrap any of these legacy applications, follow these steps:

First, build an impenetrable wall around the fortress using standard wall techniques, as described in Chapter 7 (Guards and Walls). Place a guard inside the wall, as described in the same chapter. The guard will communicate with the legacy application using the communications channels that had been used between the presentation tier and the middle tier.

From the legacy middle-tier application's perspective, the guard replaces the presentation tier. Because the legacy application was built with a formal three-tier architecture, the middle-tier portion should know nothing whatsoever about the presentation tier. Whether there is a guard or a presentation tier, as long as the communications expectations are met, the middle-tier logic can't tell the difference.

Second, define a drawbridge for the guard to protect, using any of the standard drawbridge techniques described in Chapters 4 through 6. This drawbridge will now be the "official" enterprise-level communications channel for the legacy fortress.

An overview of the process of converting a three-tier legacy application into a legacy fortress is shown in Figure 12.2.

Figure 12.2. Converting a Three-Tier Legacy Application