Modernization & The Archaeology of Software

The past is not dead. In fact, it’s not even past. –

William Faulkner

Objective

Retrieving legacy code has something to do with archaeology as both try to retrieve undocumented artifacts and understand their initial context and purpose. The fact that legacy code is still well alive and kicking may help to chart their structures and behaviors, but it may also confuse the rationale of initial designs.

Hence the importance of traceability and the benefits of a knowledge based approach to modernization organized along architecture layers (enterprise, systems, platforms), and processes (business, engineering, supporting services).

Model Driven Modernization

Assuming that legacy artifacts under consideration are still operational (otherwise re-engineering would be pointless), modernization will have to:

• Pinpoint the deployed components under consideration (a).
• Identify the application context of their execution (b).
• Chart their footprint in business processes (c).
• Define the operational objectives of their modernization (d).
• Sketch the conditions of their (re)engineering (e) and the possible integration in the existing functional architecture (f).
• Plan the re-engineering project (g).

Those objectives will usually not be achieved in a big bang, wholly and instantly, but progressively by combining increments from all perspectives. Since the different outcomes will have to be managed across organizational units along multiple engineering processes, modernization would clearly benefit from a model based approach, as illustrated by MDA modeling layers:

• Platform specific models (PSMs) should be used for collecting legacy artifacts and mapping them to their re-engineered counterparts.
  
• Since platform independent models (PIMs) are meant to describe system functionalities independently of implementations,  they should be used to consolidate the functionalities of legacy and re-engineered artifacts.
• Since computation independent models (CIMs) are meant to describe business processes independently of supporting systems, they should be used to reinstate, document, and validate re-engineered artifacts within their business context.

Corresponding phases can be expressed using the archaeology metaphor: field survey and collection (>PSMs), analysis (PSMs/PIMs), and reconstruction (CIMs/PIMs).

Field Survey

The objective of a field survey is to circumscribe the footprint of the modernization and collect artifacts under consideration:

• Given targeted business objects or activities, the first step is to collect information about locations, distribution and execution dependencies.
• Sites can then be searched and executable files translated into source ones whose structure and dependencies can be documented.
• The role of legacy software can then be defined with regard to the application landscape .

It must be noted that field survey and collection deal with the identification and restoration of legacy objects without analyzing their contents.

Analysis

The aim of analysis is to characterize legacy components, first with regard to their architectural features, then with regard to functionalities. Basic architectural features take into account components’ sharing and life-cycle.

The analysis of functionalities can be achieved locally or at architecture level:

• Local analysis (a) directly map re-factored applications to specific business requirements, by-passing functional architecture. That’s the case when targeted applications can be isolated, e.g by wrapping legacy code.
• Global analysis (b) consolidate newly supported applications with existing ones within functional architecture, possibly with new functionalities.

It must be noted that the analysis of legacy components, even when carried out at functional architecture level, takes business processes as they are.

Reconstruction

The aim of reconstruction is to set legacy refactoring within the context of enterprise architecture. That should be done from operational and business perspectives:

• As the primary rationale of modernization is to deal with operational  problems or bottlenecks, its benefits should be fully capitalized at enterprise level.
• Re-factored applications usually make room for improvements of users’ experience; that may bring about further changes in organization and business processes.

Hence, modernization is not complete until potential benefits of re-factored applications are considered, for business processes as well as for functional architecture.

From Workshops to Workflow

As noted above, modernization can seldom be achieved in a big bang and should be planned as a model based engineering process. Taking a leaf from the MDA book,  such a process would be organized across four workshops:

• Technical architecture (deployment models): that’s where legacy components are collected, sorted, and documented.
• Software architecture (platform specific models): where legacy components are put in local context.
• Functional architecture (platform independent models): where legacy components are put in shared context.
• Enterprise architecture (computation independent models): where legacy components are put into organizational context.

Those workshops would be used to manage the outcomes of the modernization workflow:

1. Collect and organize legacy code; translate into source files.
2. Document legacy components.
3. Build PSMs according basic architecture functional patterns.
4. Map to PIMs of system functional architecture.
5. Consolidate enterprise architecture.

With the relevant workflows defined in terms of model-based systems engineering, modernization can be integrated with enterprise architecture.

Further Reading

• EA: Maps & Territories
• EA: Work Units & Workflows
• Thread: Model Based System Engineering
• Traceability
• Model Driven Engineering
• Model Transformation
• Knowledge Based Model Transformation
• Legacy Refactoring
• The Economics of Reuse
• Alignment for Dummies
• Alignment: from Empathy to Abstraction

External Links

• Objektum Modernization