Displacing Legacy Systems | Martin Fowler on Patterns and Methods for Dealing with Legacy Code

[Music] the third book so the third book is sort of back to stuff that we know and have known for a long time um in a really interesting way so um this is a collaboration between um at least two of these folks you'll know james lewis and ian cartwright um and rob horn's the third guy who is newer to fort worth so you probably haven't come across it and they're working on patterns of legacy displacement how do we displace legacy systems in a more sane way and of course a lot of this is about fighting against the oh well let's spend five years building the replacement system and then we'll switch it over because we know how well that works um and but the thing is we haven't in all of the years i mean i've been in software business for 30 years or so during that whole time replacing legacy systems has been a major part of our work and yet there's not been very much written about it and not much understanding of how do we think about legacy replacements in an effective way and so what we're trying to do with this book project is capture that information again in the form of patterns yeah um so and you know because these folks have done a lot of uh legacy replacement of course that's such a large part parcel of our work and they're trying to get that information down and in place and so i'm really keen about this project because i think it's going to help a great deal to our understanding of how we best go about this exercise which is just not talked about enough um in our industry and and yet it's such a central part it's not as if it's going to stop you know as i started to say we're building tomorrow's legacy systems today um and if we can better understand how we displace them then we can build better now but we can also get through a better approach of understanding that and of course the key to this is gradual process you know you don't displace a legacy system all in one go you do it over time it may involve creating translational pieces of software that you know you're going to throw away yeah in a year or two's time but it's going to ease the process of that legacy change because it's a constant process and so it's this is early days they dropped their first bunch of patents onto the website a few months ago at the moment we've got a second batch kind of the um that's sent out to our internal review list on the infamous fort work software dev mailing list which everything has to go through um so again probably by the time this goes out that second batch will be out there and i'm really hoping this can turn into an important book as well so i think they've they've got the knowledge um they've got the desire i think to get this information out the challenge of course as for any footworks consultant is finding the time to sit and write but we're working on that i think this could be a really good book cool and and is is that so so you said there's not much written the the only one that i can think of in that in that space is michael feather's book on working with legacy code right that is this a different kind well i guess this is a slightly different kind of book to that yeah operates at a higher level because i think what we're talking about is when you've got a legacy system that again is running a whole enterprise yeah how would you replace that so we're talking about components which are themselves sizable systems you know a component of this i mean l max will be one component that you kind of said oh yeah that's l max that's a blob right how do you replace that blob with all of these lines that are connecting to it in a way that you know isn't going to drive people insane um and so we're operating at that kind of level um and so i think it's it's very much a compliment it's kind of more like the enterprise architecture um complement to what's in the in the legacy code system is how do you take a particular individual system and replace the bits of it um so there's and it's definitely going to be lots of overlap i think as i dig a bit deeper into doing that um but uh i mean i mean coach particularly i mean the first batch of patterns that the the most the key central pattern they put in was actually an anti-pattern effectively which is that of the um the feature um replication uh what was the term that i used i uh have to look at it again to remind my was the word uh feature parity right where we say oh if we're going to replace the legacy system let's build a new system that has feature parrot to the old system and i've seen smile on your face we know how that normally works out yeah so part of that pattern was to say don't do vists or at least feature parity can work but only in a very limited set of contexts and that was one of the things that we worked through in writing the pattern i dislike i'm very wary of saying something is always wrong but i am very conscious of saying well things are often used outside their context of applicability feature parity can work but it's such a narrow context that it does that you've got to be aware of that and realize that you know most of the situations we run into it's not the right context yeah and so the one of the first patterns they wanted us was to say this is where food superiority breaks down where you have to use some other kind of approach instead yeah yeah absolutely as i did just just as one of the things that was going through my head when you were describing that is many many many years ago i worked on a system that was replacing i think this is probably the third or fourth replacement of legacy systems in a car manufacturer and this was a car configuration system that described all of the different bits that came together to to to make up a car and the we were writing this in java and the core the core model that we had to retain was fundamentally based on the 80 characters of a punched card we couldn't get away from it because all of everything we laid on the relied on this massively complicated kind of um overblown customized version of some kind of weird lempo zip algorithm that kind of if this bit and this bit is set it means this so if this bit in this bit is set it means this other thing entirely and it's just it's just this overloading of information and building and testing those sorts of things it gets complicated quickly but it's certainly an interesting problem and and definitely definitely a place where there are lots of patterns to mine i'm sure yeah i mean one of it i mean i'm gonna again talk about one of the things that's currently under in the review process is a pattern that's called um divert the flow um and this is a very interesting pattern that the core heart of it is actually in another pattern there's a very sick common situation i've kind of implied it already where your business management relies upon some system that aggregates aggregates information from all over the enterprise and pulls together and it's a critical system um and we're deferred returned to in the patent terms we're calling it the critical aggregator and this is important because the key map leadership and the organization they're making decisions on a day-to-day basis that's based on this aggregation of data now having a critical aggregator is itself not necessarily a bad thing in fact usually a good thing because you want something that pulls together critical information for order to make decisions yeah the problem of is that in most legacy systems it's mestasticized into this awful thing that will reach deep into core data structures of operational systems yeah and as a result you can't touch anything because i don't change this data these five tables over here because i'm scared that it's going to break the critical light aggregator because it's a critical aggregate it's critical it has to keep running yeah so how do you deal with this so one pattern that the um that uh was being they're writing up at the moment is called divert the flow and divert the flow says it's kind of counterintuitive in the way but it says the first thing you should replace in a legacy system is often that critical aggregator rebuild the critical aggregator and give it better interfaces so that you can actually substitute the input points better yes um the alternative is basically when you is replacing the the upstream systems but creating the legacy mimic that sort of looks like the old system so the aggregator can still work because usually the problem with your legacy okay is you can't replace its connections because they're just so deeply intimidating so you have to pretend the old systems are still there with your new ones yeah the problem with legacy mimic though is if you use a legacy mimic yeah it complicates the building of the new systems because you've got this more messy thing to deal with but it also means if you've got opportunities to provide new information that would be really handy for the critical aggregator you can't do it because you can't go through that legacy connection well if you replace the critical aggregator first it gives you greater safety in replacing the other parts of the system because you've got a much more sane time to the critical aggregator but also if you're now using some information but you didn't have it before you've got the opportunity to feed it into the critical aggregator because you can update the critical aggregator to use that new information and so even though it's counterintuitive because you kind of feel well that's the critical aggregator i don't replace this first because it's scary yeah often replacing it first can be the best route to go and so that's a pattern that we that they're referring to is divert the flow and the the the divert the flow is a is a metaphor of saying but if you if you want to replace um a dam the first thing you want to do is divert the flow of rivers so that you can work on the dam without having it be affected by the so upstream so once again referring back to eric evans you you're going to you're going to use that and start to build anti-corruption layers to to allow you to assemble the new the new critic the critical aggregate yeah yeah so that's the kind of pattern work that they're doing so that gives you a sense of the level of the operation yeah and how it relates i think to the the that's michael fevis's work um and i'm i'm very keen on seeing how this kind of stuff develops because this is definitely stuff we've done many times with our clients over the years and often the challenge is getting people to understand the trade-offs involved because the trade-offs are um often not straightforward because people do come into this in the sense of oh let's just go for feature parity and move it to the cloud yeah and we go no that's probably not what you really want to do um and if if it's really a legacy system you probably don't know what all the features are anyway because all of the people and the people have gone in the dock it's not they're poorly documented well exactly and of course often it's doing things that you don't want it to do indeed yeah and so so yeah there's a lot of stuff around that so i'm keen to see this one and so so there you see the three um books i'm mentoring and the intellectual whiplash that i go through switching from one of those [Laughter] i i i said in your intro that you had a broad perspective [Laughter] thank you marcy [Music]

Channel: Continuous Delivery

Views: 16,024

Keywords: martin fowler, martin fowler interview, legacy code, legacy systems, replace legacy systems, displacing legacy code, software patterns, patterns of distributed systems, critical aggregator, critical aggregator pattern, refactoring, refactoring legacy code, distributed systems, software development, software engineering, computer science, Dave Farley, software podcast, software interview, the engineering room, thoughtworks, martin fowler talk

Id: lwP80OiKtXI

Length: 12min 3sec (723 seconds)

Published: Sun Aug 14 2022