Martin Fowler recently published a series of articles called Patterns of Legacy Displacement. It summarises the authors’ collective experience in replacing legacy systems. They argue that chances of success are increased by dividing such projects into three phases and following the patterns listed for each one.
The articles describe three significant steps to replacing legacy systems successfully: understanding the desired outcomes, breaking the problem down, and delivering incrementally. Available design and process mapping patterns support these steps. This first installment focuses on the organisational structure and details the Extract Product Lines and Feature Parity patterns for problem decomposition.
Ian Cartwright, Rob Horn and James Lewis write that all legacy systems replacements should include improvements to business processes or organisational structure changes that allow continuous delivery and match the desired reality of business processes. They point out that "[their] observations from (...) organizations is that technology is at most only 50% of the legacy problem, ways of working, organization structure and leadership are just as important to success."
The authors found that aiming for a "big bang" replacement while the rest of the organisation continues to work as usual is often a recipe for failure. On the one hand, the two systems diverge considerably over time; on the other hand, ways of working within the organisation evolve organically to work around the legacy system’s limitations and are frequently out of sync with the business processes duplicated into the new system. They argue that "if teams and their communications are organized around the existing legacy solution and processes we may need to reorganize them using the Inverse Conway Maneuver to match the new solution and its architecture."
The first step of legacy system replacement is to understand the desired outcomes, according to the authors. They point out that "it is vital for an organization to agree the outcomes they want to achieve when tackling legacy. While this may seem obvious, all too often different parts of an organization can have quite different views on the desired outcomes." Some typical legacy replacement outcomes are reducing the cost of change, improving business processes, retiring old systems that are no longer supported or overcoming market disruptions by new players. The authors add that introducing new technology should never be a goal by itself; it must support the current and predicted needs of the business instead.
The second step is to decompose the problem into smaller parts, the authors add. They note that "many applications are built to serve multiple logical products from the same physical system. Often this is driven by a desire for reuse. (...) A major problem we come across is that superficially the products look similar but they [are] very different when it comes to the detail." The Extract Product Lines pattern reduces risk and divides the legacy system into slices that can be (re)built simultaneously and delivered incrementally. Slices are extracted by discovering the product or product lines in the system and their business capabilities. The authors then prioritise the extraction of the products found by risk and begin with the second riskiest, maintaining the business’s attention but not risking a significant failure in case of problems.
Aiming for feature parity is often an underestimated goal and is not recommended except for a few use cases, the authors write. They even state that "if feature parity is a genuine requirement then this pattern describes what it might take to do well. It is not an easy path, nor one to be taken lightly." It requires running complete system surveys to understand user journeys and the system’s inputs and outputs, integrations, and batch processes. Such surveys often need to be complemented with systems archaeology to discover their inner workings, instrumentation to discover what is being used, and feature value mapping to understand which features may be dropped. Naturally, tests must be used to ensure that the new system behaves like the old one. The authors conclude that because this pattern is so expensive, it should only be used when all specifications are well known or when any changes would disrupt existing users too much.
During their past work, the authors found that Event Storming helped them extensively during the discovery process. They argue that understanding the problem "means getting as good an understanding of the current systems and architecture as possible in the shortest amount of time. This is often super hard to do and it's easy to get bogged down in too much detail." Tools such as Event Storming or Wardley Mapping and user feedback are essential to map business capabilities to the existing architecture and to understand how that architecture creates value during the first step.
Lists of other patterns that readers can use during each step are provided but not detailed. The authors are technical directors at Thoughtworks and intend to publish more of their way of working as patterns.
