Enterprises and legacy systems, an inevitable combination…. Product teams working in somewhat uncoordinated and incoherent fashion. Bunch of old, yet difficult to maintain, systems that still bring massive value to the customers. Classic anxiety that some unlooked-for startup will snatch our customers attention. What’s there to prevent them choose shiny new technology over our grumpy legacy product? All this causes an internal awareness to grow that things need to change. At this point, the enterprise usually embarks on a modernization journey. Yet, in what direction and how?
Many organizations are trying to modernize their core-business legacy systems. Usually envisioning a super-modern system replacing the old one. Many of us never get there.
Try instead to discover what is actually possible to achieve in your particular context.
On one such modernization journey we applied the following simple, yet rather demanding recipe.
We called it the “Pilot Team Approach for Legacy System Modernization”:
Enterprises in particular are always on different levels of maturity. When we start with a modernization we are facing a lot of old design decisions, made in historical circumstances that were probably right at the time, but did not scale well.
The Pilot-team approach allows for finding the most appropriate model of the software system that is both an obvious improvement for the organization as a whole and, more importantly, will be possible to implement.
In this story we were such a Pilot team, however we still had a regular product assignment.
This is a crucial assumption: To experiment with boundaries in the system, you need a real use-case as a testing ground
The product assignment itself was about developing a support for building dynamic content for customer letters. Any letter had a letter template with placeholders for the information to be filled by a content provider owned by different teams.
The figure above illustrates content providers, in this case: “Organization”, “CurrentUser”, “Customer”, “Address” and “Order”
There were hundreds of different letter templates already defined in the legacy system. To avoid asking our customers to define them all over again we decided to re-use all the templates.
Note that this decision minimized the impact on our customers! At the same time, this turned out to have an equally important impact on the system design:
The next step was to align this subdomain perception with new system design. Especially since legacy systems rarely expose the boundaries in a good way.
This meant that we needed to derive the target bounded context from the letter templates. This required establishing corresponding, but explicit boundaries in the new system.
In DDD terms, an observable system boundary is called a Bounded Context. This always represents a choice made by system designer, however that choice was made.
Deriving target bounded contexts involved mapping existing bounded contexts to each placeholder in the letter template. In case no such context existed, create a new one. The figure above shows an example of target bounded contexts with relations derived from the letter template.
Bear in mind that we were supposed to minimize the impact on other teams. Creating new bounded context without assigned technical ownership would not achieve much. Instead, our strategy was to establish a separate module within an existing contexts. By providing support to the owning team in the transition period, we would gradually establish the ownership of the new module.
In some cases it was obvious that the new module belonged to another bounded context. Perhaps even one that did not exist at a time. Thus, we often had to wait with the move to a designated target bounded context. The following figures illustrates some of the concrete Target Bounded Contexts and the way we went about assigning responsibility for new functionality
This way we were exercising steps 2 and, to some degree, step 3 from our “Pilot Team Approach for Legacy System Modernization”. We had, obviously, a backlog of work related to establishing new and cleaning up the existing bounded contexts. To finish this, we were dependent on the support of the technical coaching staff and the rest of the organization.
Clearly, it was important to motivate the other teams to fulfill the work we had started. This, in particular, is the primary role of having a technical coach in each team. Somebody that argues for doing design and architecture modernization work. All as a part of regular product assignments.
Following this strategy we found ourselves in a typical situation for enterprise environments. To fulfill the end-user need, we had to put in place changes across multitude of functional areas.
The Pilot team usually ends up working across the existing boundaries.
This is where step 1 from the “The Pilot Team Approach for Legacy System Modernization” comes into play. The modeling and technical excellence is paramount for the team to move across different domains and codebases.
In our case, we tried to establish very similar code structure in any new module we added. Our common approach was hexagonal architecture style.
The choice of the architecture style is very much context sensitive and is by no means an absolute recommendation. The important thing is to have a common approach in the Pilot team that makes the new code recognizable for the team and others. Almost like a sign-posts left by the Pilot team for others to follow.
Equally important is to have at least one person with deep domain knowledge of as many of functional areas as possible. This helps to hit the ground running when entering a new domain. This is a not easy to get in many organizations, yet an essential prerequisite for a Pilot team.
Further Study:
CoWork AS (917 535 450)
hei@cowork.no
+47 934 01 522