Legacy & Modernization

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

Preamble

Despite the experience of practitioners, most EA frameworks overlook legacy issues assuming that enterprise architectures, like their physical cousins, can be built from blueprints. But they are not because business context and competitors cannot be put on stand-by while work is in progress.

EA’s Legacy: WIP or RIP ? (Hans Vredeman de Vries)

So, whereas some refactoring is better dealt with at application level, modernization should be put at the core of EA concerns.

Refactoring

Whereas model transformation follows the arrow of time, taking expectations and commitments one step further towards application deployment, refactoring goes the other way, taking back past implementations in a bid to understand their purpose and keep the memory alive. Likewise, contrary to reuse which stands on transparent and secure foundations, refactoring delves into unfathomable, unreliable or even decaying code in the hope of retrieving reusable nuggets.

Theoretically, refactoring could be set at three basic levels:

  • Reuse of code within a different technical context.
  • Reuse of models to produce new implementations.
  • Reuse of requirements to be realized into a different architecture.

In practice, between reuse of code and its limited applicability, and reuse of requirements a mixed one, models reuse should be the solution of choice.

AlambicBw
Reverse Engineering: Full Throttle Backward ?

Set within a model transformation perspective, that can be done from design or analysis models:

  • Implementation: legacy code is wrapped into a new design and redeployed as it was.
  • Source: legacy code is redesigned and redeployed.
  • Functionalities: applications are redesigned.

The objective is to consolidate the different refactoring policies and put legacies and new developments within a single framework.

Refactor_ReAnD
Putting Past and Future under a Single Modeling Roof

Model Driven Refactoring

Obviously one cannot expect to find legacy systems neatly organized along architecture layers, and the first assignment is therefore to inventory legacy components as deployed, and try to map them against basic architectural tiers. For that purpose it will be necessary to determine whether components make use of persistent information, and whether they are executed locally or may be shared. When components cannot be fitted to a single tier they are assigned by default to the upper one.

Refactor_All
Model Driven Legacy Refactoring

The next step will be to consider components at code level in order to extract design backbones (PSMs) and try to map structures to architecture patterns like Boundary/Control/Entity (aka Model/View/Controller). At that stage a repository of attributes and operations should be established and mapped to features and functionalities as documented by business requirements (CIMs).

Finally, the objective is to match the outcome to the functional architecture as defined by platform independent models (PIMs).

FROM WORKSHOPS TO WORKFLOW

Modernization can seldom be achieved in a big bang, hence the benefits of model based engineering approaches. Taking a leaf from the MDA book,  modernization 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 & MBSE Workshops

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

Modernization & Enterprise Architecture

Enterprises are live social entities made of corporate culture, organization, and supporting systems; their ultimate purpose is to maintain their identity and integrity while interacting with environments. As a corollary, changes cannot be carried out as if architectures were just apparel, but must ensure the continuity and consistency of enterprises’ structures and behaviors.

That cannot be achieved by off-soil schemes made of blueprints and step-by-step processes detached from actual organization, systems, and processes. Hence the benefits of mapping legacies to architecture capabilities:

Pentaheds-Layers
Layers of Capabilities

The next step would be to define modernization from an enterprise architecture perspective:

  • Changes in business objectives that require changes in systems functionalities (a).
  • Changes in operational environment that require changes in systems capabilities (b).
  • Changes in systems functionalities that induce changes in systems capabilities (c).
RekReuse_legacy
Architectures Modernization

It must be noted that modernization can be initiated at any level (enterprise, systems, or platforms), and that changes can be propagated backward, e.g from capabilities to concepts and functions.

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 changes across enterprise architectures.

Further Reading

Leave a Reply

%d bloggers like this: