At the DDD Exchange conference today in London, Eric Evans presented on “The good, the bad and the ugly” aspects of strategic design. Talking about several efforts to replace legacy systems he has encountered in past, he suggested that these were “traps that good and smart software people are more likely to fall into” [than those with less experience]. According to Evans, none of the conventional approaches to that problem are likely to succeed.
A goal that is often set for projects such as these is “let’s switch off the legacy system”, but the first trap is that it gets mixes with a major redesign of the system as well. Calling this a classic mistake of not having a separation of concerns, Evans suggested that the goal of switching the legacy system off is not a real strategic goal unless it is really really expensive to run. Very often the real problem is that a legacy system does not allow people to develop and deliver efficiently.
Phased approaches fail
The approach of redesigning a whole system from scratch typically gets split into three phases: designing and implementing the basics, completing the features of the old system, and then implementing some new and really exciting features. Projects like this will most likely end up in failure, as the team spends lots of time on the first two phases and does not really get there completely, and also the business cannot stand still while the project is going on. The system simply cannot be delivered quickly enough. At some point, companies decide that they have to get the new features done, go back to the old system and continue implementing key new features on it.
Replacing piece by piece fails
Another common wrong approach is to refactor a legacy system piece by piece, extracting parts and cleaning them up. According to Evans, these efforts fail because they are an uphill battle. Extracting and integrating every piece is going to be always very hard because of the friction between the designs, and every time a part of the system gets nice it “draws other programmers like flies”, because everyone wants to do their work quicker by now using this new model. The nice model collapses under load as people who don’t understand it continue hacking in it.
Instead, focus on the core domain
The way that these efforts are most likely to end up, according to Evans, is just continuing hacking on the legacy system. Yet this is exactly the place that teams did not want to end up at and the reason why the replacement effort was started. These approaches all undermine the core idea of the value of design and make companies not want to invest at all in good design.
Starting from a proposition that “not all of a large system will be well designed”, Evans suggested identifying and focusing on the core domain – a very small piece of software that actually makes the system really worth writing, something that brings direct competitive advantage to the business. These are most likely those new and really exciting features that people plan to do after the functionality of the legacy system was fully replaced. Instead of waiting several years for the old system to be replaced before core features are enhanced, teams should focus on efficiently extracting and isolating that part of the legacy system and redesigning that directly. In order to be able to build just that part, it should be isolated with an anti-corruption layer that reaches into the old system and retrieves the information that the new elegant core needs, converting it into the new model.
