Modeling Legacy Assets

What technical challenges will you face when integrating your new application with existing systems? Part 1 of 2.

Every business application that I've helped to build has had to integrate with legacy assets—either legacy data, legacy functionality or both. Yet most software development books lack a coherent discussion about dealing with, and often interfacing to, legacy assets. You may find a brief discussion of how hard it is to work with legacy assets, but little more than that. In this newsletter, I review the issues involved with modeling legacy assets.

At the project's start, you'll invest time developing initial requirements and architecture models. If you're taking an Agile Model Driven Development (AMDD) approach, these models will be very slim. One aspect of your architecture model will be your best guess as to which legacy assets, if any, your system will need to interface with. You probably won't get it 100 percent right at first—during future development iterations, you'll discover that other legacy assets may be more appropriate than those you first identified.

During development, you'll need access to the documentation describing how to interface to each legacy asset, something that Agile Modeling (AM) refers to as a contract model. Contract models are often necessary when an external group controls an information resource that your system requires, such as a database, legacy application or information service. A contract model is formalized, with both parties agreeing to it, yet ready to change it as needed. Examples of contract models include the detailed documentation of an application programming interface (API), a file layout description, an XML DTD or a physical data model describing a shared database. As with a legal contract, development and maintenance of a contract model often requires investment of significant resources to ensure that it's accurate and sufficiently detailed. Your goal is to minimize the number of contract models so that your system conforms to the XP principle, "Travel Light." Note that you'll almost always use an electronic tool to develop a contract model because the model must be maintained over time.

Consider yourself lucky if you have up-to-date contract models—in many organizations, legacy assets are poorly documented (if at all), leaving it up to the next team to update the documentation to a usable level.

Writing contract models for legacy assets can be difficult: You may not have access to the actual source code (if it exists), or to anyone who understands the asset, let alone someone who originally developed it. The asset's owners may not wish to have it documented, usually out of fear that the asset will be replaced and they'll be out of a job—or, if they're willing to work with you, they may not have the necessary resources.

Let's assume that you're able to overcome any technical or political obstacles and have complete access to everything and everyone that you need. Creating contract models is still a tough job, due to technical challenges with the legacy assets, including problems with data quality, code quality, design and architecture. Let's consider each in detail:

1. Data quality. When it comes to data, a wide range of quality problems can occur: a column or table used for more than one purpose, missing or inconsistent data, incorrect formatting of data, multiple sources for the same data, important entities or relationships that are stored as text fields, data values that stray from their field descriptions and business rules, several key strategies for the same type of entity, different data types for similar columns, and varying default values. This list is nowhere near complete, but should give you a feeling for the challenges you'll face.

2. Code quality. Similarly, you're likely to find problems in legacy code, such as inconsistent naming conventions, inconsistent or missing internal documentation, inconsistent operation semantics and/or signatures, highly coupled and brittle code, low cohesion operations that perform several unrelated tasks, and code that's simply difficult to read.

3. Design. Your legacy assets may suffer from significant design problems; for example, access to data sources may not be well encapsulated or the encapsulation strategies may be difficult to use. Applications may be poorly layered, with the user interface directly accessing the database. An asset may be of high quality, but its original design goals may be at odds with current project needs.

4. Architecture. Architecture problems are a serious challenge with many legacy assets. Common problems include applications that are responsible for data cleansing (instead of the database), incompatible or difficult-to-integrate platforms, fragmented and/or redundant data sources, inflexible architectures that are difficult to change, lack of event notification impeding real-time integration support, insufficient security, and assets with varying timeliness (for example, databases updated on differing schedules).

Analyzing a legacy asset is only part of the solution: You also need to design a strategy for interfacing with it. Among the many approaches for doing so, you can wrap access to the asset with Web services, a C-API, or simply via screen scraping (in which you simulate keystrokes in the user interface). Gregor Hohpe and Bobby Woolf et al.'s Enterprise Integration Patterns(Addison-Wesley, 2003) describes a large number of architectural patterns for integrating with legacy assets.

Stay tuned. Next month, I'll discuss strategies for overcoming these problems and pitfalls.

>>HOT LINKS

To learn more about the issues involved with analyzing and transforming legacy assets, read William Ulrich's book Legacy Systems: Transformation Strategies.
http://www.amazon.com/exec/obidos/ASIN/013044927X/ambysoftinc

Ulrich's site, the System Transformation Home Page, has several very good whitepapers on legacy analysis.
http://www.systemtransformation.com

To learn about design techniques for integrating with legacy assets, read Gregor Hohpe and Bobby Woolf's Enterprise Integration Patterns: Designing, Building and Deploying Messaging Solutions.
http://www.amazon.com/exec/obidos/ASIN/0321200683/ambysoftinc

Agile Model Driven Development (AMDD) is described in detail at
http://www.agilemodeling.com/essays/amdd.htm

The Agile Alliance homepage is the best starting point for anyone interested in learning more about agile software development.
http://www.agilealliance.org

The Joy of Legacy Data describes in detail many of the issues pertaining to legacy data.
http://www.agiledata.org/essays/legacyDatabases.html

The principles of Agile Modeling are described at
http://www.agilemodeling.com/principles.htm

The practices of Agile Modeling are described at
http://www.agilemodeling.com/practices.htm

Check out the Agile Modeling mailing list at
http://www.agilemodeling.com/feedback.htm

Get Agile Modeling training resources at
http://www.agilemodeling.com/training.htm