From the Agile Modeling newsletter, the first part of 2: what technical challenges will you face when integrating your new application with existing systems? Scott Ambler explains how he deals with this.

Practically every business application has 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.

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.

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.

Things that come into play:

• 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 etc.
• 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 etc.
• 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.
• 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 and so on.

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.

When I can get hold of part II I will publish some more of Scott Ambler's thoughts.