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.
Legacy Artifact: Was the bowl intended for turkeys? at thanksgiving ? Why the worm ?
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).
Modernization Road Map
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.
Model Driven Modernization
Corresponding phases can be expressed using the archeology 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.
Analysis (with regard to presentation, control, persistency, and services)
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.
Analysis (with regard to presentation, control, persistency, and services)
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.
Reconstruction
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.
Modernization workshops
Those workshops would be used to manage the outcomes of the modernization workflow:
- Collect and organize legacy code; translate into source files.
- Document legacy components.
- Build PSMs according basic architecture functional patterns.
- Map to PIMs of system functional architecture.
- Consolidate enterprise architecture.
Modernization Workflow
I found this blog post, written by Remy Fannader on LinkedIn. He perfectly captures the essence of why we at Objektum Modernization provide the technology that we do.
Thanks for reading
Derek Russell
derek@objektum.com
08451999932
No comments :
Post a Comment