This post is a small review of the post written by Ian Cartwright, Ron Horn and James Lewis. Their post is not only a description of good practices but also you can hear a good podcast where they discuss the subject: Patterns Legacy Displacement.

They prepared a set of patterns (or suggestions) to help to make decisions when we are working with legacy code. I'll not go deeply here because their explanation is very complete and helpful. More details you can go directly to the original post. Here, I want to take some notes to make my life easier when I need to review the concepts. Maybe it can help you too.


init()

The technology is at most only 50% of the legacy problem, ways of working, organization structure and leadership are just as important to success.

Some points that can lead to failures:

  • Change the technology but not change the other parts involved (structure, way to work, leadership).
  • The gap between what the business actually needed and what was actually signed off at the start of the plans.
  • Feature Parity: What exist should continues working in the same way. It is the "as-is" functionality, The challenge here can be in the definition and agreements.

The Feature Parity is to delivery the same functionality but with different technology. It can be very useful, for sure. However, the team can be loosing opportunity to improve the system and cut not used features.

The authors give as alternative the approaches:

  • Extract Product Lines or Extract Value Streams: give strategies for identifying thin slices through an existing system. By splitting by product we are taking advantage of the fact that changes to multiple products can be made simultaneously, and reducing risk by avoiding the combinatorial explosion of changes that may introduce defects in unwanted places.
    • Identify the product or product lines within the system.
    • Identify shared capabilities.
    • Choose who goes first.
    • Identify your target software architecture
    • Identify your technical migration strategy.
  • Looking at the business value and making sure that is represented in any architectural decisions can often highlight issues with Feature Parity driven approaches.
  • Treating technology and business process as part of the same problem. Just replacing the tech will leave at least half the problem unsolved.

logger.info("Starting....")

Categories of direction to identify the priority:

  • Reducing the cost of change,
  • Improving the business process,
  • Retire an old system,
  • Imminent Disruption (external event)
  • Newer technology
  • Decide how to break the problem up into smaller parts
  • Successfully deliver the parts
  • Change the organization to allow this to happen on an ongoing basis

Resources to break the problem in smaller parts and which will help to understand it:

  • Event Storming
  • Wardley Mapping
  • Business Capability Mapping
  • Domain Mapping

The patterns

Here I just print the patterns discussed in the article by the authors.


Ref: Patterns of Legacy Displacement

And here some other patterns:

  • Versioned Value: to validate the most recent data
  • Write-Ahead Log: Provide durability guarantee without the storage data structures to be flushed to disk, by persisting every state change as a command to the append only log</em>
  • Leader and followers: Replicate the write-ahed log:
  • Segmented Log: Split log into multiple smaller files instead of a single large file for easier operations.
  • Low-Water Mark: An index in the write ahead log showing which portion of the log can be discarded.
  • Singular Update Queue: Use a single thread to process requests asynchronously to maintain order without blocking the caller.
  • State Watch: Notify clients when specific values change on the server

exit()

The article has two podcasts about the subject. Take a look at those links.


REFERENCE