The past is not dead. In fact, it’s not even past.
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.
So, whereas some refactoring is better dealt with at application level, modernization should be put at the core of EA concerns.
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.
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.
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.
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).
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:
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).
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).
Those objectives will usually not be achieved in a big bang, wholly and instantly, but progressively by combining changes across enterprise architectures.
- Where to Begin with EA
- EA: Maps & Territories
- Legacy Refactoring
- Modernization & The Archaeology of Software
- Models Transformation
- Knowledge Based Model Transformation
- EA: Work Units & Workflows
- Focus: Enterprise Architect Booklet
- Emerging Architectures
- Ontologies & Enterprise Architecture
- Ontologies as Productive Assets
- Caminao & DoDAF
- Models, Architectures, Perspectives (MAPs)
- Views, Models, & Architectures
- EA: The Matter of Layers
- Architecture Capabilities
- Feasibility & Capabilities
- Abstractions & Emerging Architectures
- Why Virtual Reality (VR) is Late
- Focus: Individuals in Models
- Agile Architectures: Versatility meets Plasticity
- A case study