Every system becomes legacy the moment it’s built. In this insightful session from Prodacity 2025, Joe Szodfridt, Sr. Solutions Principal at Nearform, explores the pitfalls of legacy modernization, why so many teams get stuck, and how to take a continuous approach to software evolution.

From overloaded documentation to misguided domain-driven design (DDD) efforts, Szodfridt highlights how teams can simplify their approach, break free from analysis paralysis, and create a living system that evolves over time—without high-risk, high-cost rewrites.

🔹 Key Topics Covered:

• Why legacy systems aren’t just old—they’re mission-critical
• The illusion of completeness: How teams get lost in documentation
• Why modernization is continuous, not a one-time project
• How thin slices improve focus & reduce noise in system design
• Why domain-driven design (DDD) isn’t enough on its own
• How to balance business needs, user expectations & technical constraints

🕒 Key Highlights & Timestamps:
[00:04] - Introduction: The challenge of modernizing core legacy systems
[02:00] - Why software is outdated the moment it’s built
[03:54] - The trap of over-documentation & analysis paralysis
[06:30] - How systems want to behave vs. how they actually work
[08:10] - Creating high signal, low noise in system design
[10:35] - Why domain-driven design (DDD) is hard for non-technical stakeholders
[12:45] - The problem with insider vs. outsider knowledge in system development
[14:58] - Thin slices: A better way to approach system evolution
[16:42] - How event storming reveals system bottlenecks & modernization opportunities
[19:10] - Using red stickies & async events to model real-world workflows
[21:28] - Mapping legacy systems onto future-state models for low-risk modernization
[24:46] - Final thoughts: Simplify, collaborate & modernize continuously

🔗 Stay Connected:
Learn more about Prodacity: https://www.rise8.us/prodacity
Follow us on X: https://x.com/Rise8_Inc
Connect with us on LinkedIn: https://www.linkedin.com/company/rise8/

👍 Like, Subscribe, and Share:
If you’re tackling legacy system modernization, domain-driven design, or continuous software evolution, give this video a thumbs up, subscribe to our channel, and share it with your network. Modernization isn’t a project—it’s a mindset.

‍

Joe Szodfridt (00:04):

I've been working with a customer for the past month. They're modernizing their legacy system. It's their core system. It runs their business. It's a big financial institution. A lot of money runs through this. They've been doing this for months. It's huge. They have like 40 teams. The engineers are measured in hundreds. Okay? This is a big thing that they're working on and they're doing domain-driven design. That's the process that they picked to start going down to redesign their architecture of this legacy system. They've been doing this for a while. They've figured out their domains, their personas, their value objects, their aggregates, but somehow they still are stuck somewhere. That's where they called us and they showed us their documentation. And trust me, they have tons and tons and tons of documentation. They're literally drowning in their own documentation. They got so many stickies. I've never seen so many pictures of so many stickies.

(01:05):

Now, I love stickies. I used to joke that if I had enough stickies, I could probably rule the world. I still love stickies. They're still very useful. All the tactile simple things are very, very good collaborative tools. They have sequence designs, context diagrams. They've digitized every single event storm with all the right domain driven design colors, and they have it everywhere, but it's too much stuff, but they don't think it's enough stuff, which blows my mind. How could you do so much work yet still feel that you can't get anywhere? That's what they called us in. So welcome to the world of continuous modernization and what is continuous modernization? I use the word continuous because any system is legacy almost a day you build it, right? You'd write something today, by tomorrow, there's some new tech, there's some new AI LLM that's going to outright your code style.

(02:00):

There's some new framework, there's some new agile framework. There's some new design framework. There's something new and your systems are always going to be slightly behind. And then there's the systems that are core systems that run your business that are really, really behind, but they're very valuable and trying to rewrite those is a very dangerous thing. There's very many tools now. It's making better. It's easier than it used to be, but it's still a risky proposition. You have to take the system you have in place and incrementally, continually modernize it. Find the areas, find the seams that provide value and make them better. And so who, it's a little foggy road though. It's not very clear. There's a lot of pitfalls on this road. As Bryon mentioned in my bio there, my career started doing industrial automation and I'd love that stuff. I wrote software that made machines and factories run, and I'll tell you, there's nothing more satisfying to me anyway, seeing all this mechanical stuff flying around and not crashing into each other.

(03:01):

I did some agile transformation, made a lot of stodgy waterfall companies into high performing software development delivery machines, companies, and as Bryon said, I'm one of the original members of the application transformation group at Pivotal, where we did lots of really cool things. And my experience through all this continuous modernizing of different types of systems in different types of spaces tends to have a lot of noise, right? All these processes that we have, domain-driven design, agile processes, value stream maps, they're all there to amplify signal. We want the information, but somehow we're always stuck in these very noisy processes where some of the processes and documentation that we do get in the way. The other thing that we're missing, and we heard this is a kind of repeating theme throughout the day here and yesterday, is that we need a place where everyone can collaborate.

(03:54):

We need some kind of common canvas where the technical people and the non-technical people and the business people and everyone who's involved in a system can kind of scribble on a page and communicate and talk to each other and understand this big thing that everybody's trying to work on. So we have kind of a problem here that we don't have these things, but let's go back a little bit to define what a system is. Now, a legacy system could be made up of many, many things. It could have mainframe over there. It could have some cloud computer over there. It could have some microsurfaces over there. It could have something written in Fortran, something written in Pascal, something written in go, or whatever language you want. Big systems have lots of components developed by lots of different people, but there's other things too. There's things like checklists, paper checklists, right?

(04:46):

There's people picking things off shelves, there's spreadsheets, a lot of shadow it, and then there's people who actually have conversations, people having a conversation, making a decision is part of the system. They all need to be modernized. They all need to be captured. They all need to be accounted for. If you're just looking at the technology, you're missing a part of the system. Everything is a part of this system. Everything that produces something to get that job done is part of that system that you need to build something to account for. This stuff is locked up though. It's not easy to extract. As you saw from my previous example, my customer there, they're doing tons and tons of work, but they still don't have the stuff that they need. They feel this stuff is locked up. It's difficult to extract all the components of a system.

(05:37):

I think we're almost in a situation where as engineers, we become masters of documentation, but we lose the intent. The intent is locked up. It's locked up because we build all these processes and systems around it, and it's keeping it away from everyone who needs to participate in designing these systems. So what do we see? Well, we have lots of smart processes. We have domain-driven design. We have all kinds of cool code inspection tools. They're really good at finding out what is the current state of the system. And yes, they can project forward and they can give you some kind of insights into what the future should be. But their strength, their strong suit is really is how things, what is. We have people on the other side, people, they're a little more vision oriented. They're a little more dreamers. They look into the future.

(06:30):

They're better at thinking about how things want to behave or how the future could be as opposed to the way it is. They're very good at spotting subtle clues, how people interact, how people want to work with the system, how the system wants to behave. And that's a term that I like to use when we're talking about systems. How it wants to behave is remove the barriers of the way things are, the current process that you have. And if you could just build it naturally, the system was human beings instead of machines. How would it naturally flow? How would it work if it was not a machine or computers? Try to put yourself in the shoes of all these giant systems are really people and how those people collaborate, how do they try to do their work together? That's what they're trying to get to.

(07:13):

That's that vision. How the system wants to behave. So we need to put some humans in this process loop here with all this cool whizzbang tools that we have to design software and interrogate software and give us the real world. We have on the one side, we have the processes and they're really good at shedding light, as I said, on what is, but they're a little jargon filled. They're sometimes rigid. They can be complex. We have to put in that human variable where the humans can shed light on the way things want to be. Humans are more collaborative. Let's hope that we're more collaborative and they do have that vision. They're dreamers are people, right? If we put those two together, that's when we start having the real innovation. That's when we get enhanced clarity of the system. People understand what it is, they talk about it, and we try to get rid of all those cross communications that people are having and stumbling around when they're talking about a large system.

(08:10):

What we're trying to do is we're trying to create a very high signal to noise ratio. We want a lot of signal, low noise, and we want a common canvas where everyone can work together. So I like DDD I like domain-design. It's got lots of good things in it. It's a well-designed process. It creates great systems, but it's not always the best solution in every single scenario. These are some comments that I heard from this customer that just in a meeting when I was doing this presentation, I'm like, this is fantastic. These are perfect. You didn't even know I was doing this presentation, and he just rattled these off in a meeting. And so I wrote 'em all down. He says, this isn't enough. And I told you that they're drowning in their own, yet he feels they don't have enough. It's not a living thing.

(09:00):

So they think that everything that they're doing is static. Static is a very difficult way to design software because everything is always changing. He said they can't go deeper easily, and this one cracks me up because they've gone so deep. They're down so deep in the weeds with all their documentation, but they feel that they can't go deeper. So I don't know what deeper means in their case. And he said, how do we get to the next level? And I think he still means getting more deeper, more design, because they have a lot of documentation they can't get somewhere. But to me, I think he's thinking about this wrong. I think the next level is not going deeper. It's going higher. It's going a little bit higher to a more logical holistic view that everyone can gather around and focus on and build the system together, extract all those hidden pieces and all that process.

(09:52):

He said, now what? He said, we've done all this work. They've been working on this for like six, eight months now, and they have a deadline of releasing something by May. They haven't even planned it yet, and they have to have their very first relief of their working software by the end of Q2 or three and don't, they're stuck. They're really in a bad place yet. They've been working like crazy on this, generating information out the wazoo. So DDD has a lot of good things about it, but there's a lot of words you got to know and concepts you have to understand. There's things like bounded context and a value object, and you do things like context mapping. Put your hands up if you know what any of those words mean. If you do, you're on this side of the page here where people get it.

(10:35):

There's lots of smart people who know this process. They know the words. They can converse, they can design systems, very good systems with this process. On the other end, there's people who don't get it. They're the non-technical people. They're stakeholders. There's business people, they're users. They're also part of that process. Remember, think that that process is a big thing. Everyone's in that process. They are very valuable input. When you're redesigning a system of how it should behave, how it wants to behave. There's a third kind of person too. This is the kind of people who really get it. And what they tend to do a lot of times is they'll disagree with you. They will tell you that that's not a bounded context. Your definition of an aggregate doesn't satisfy the definition of an aggregate. They also have valuable input. So we're losing our way a little bit here.

(11:24):

We got all these processes, but we're still not pulling people in and we're still not building this common canvas to work with. DDD is kind of hard to learn. I try to find some statistics, and you can see here that just to learn the basics, it's a few months just to understand the words to become a master. After five years, it's like 20% of people still haven't mastered this process. How are we going to expect to get nonbusiness, non-technical people, rather business people and users involved in this process? This is a lot of stuff for them to learn. So we know that d, DDD is complex. I still like it, but it is still complex. There's a lot of things that it has, and I see that it has a lot of noise. If you understand that if you're on that side of the page or the people who get it, it has high signal, low noise to you, but if you're on the other side of the page, the people who don't get it, it's a lot of noise, low signal, and that's not a good one. We're trying to bring everyone together. It's also missing that common canvas of something simple to understand where people can collaborate and work together. If you get it, you'll understand it. If you don't, you're kind of left out in the dark. You may say, Joe, that's blasphemy. Domain-driven design is the best thing ever. It has value, but my experience is it needs to be a little simpler. It needs something more to make it inclusive and to get the benefits of building large systems.

(12:45):

So it has a very steep learning curve that makes it very difficult for the non-initiated people to contribute to this valuably. The language makes it difficult to talk to each other. If you speak French and you speak German, you probably have some common words from a dictionary, but you're not going to understand the intent. It's the same way when we're doing DDD real heavily using that vocabulary. And mainly it does have an outsider type of focus where people who don't get it, they're, they're excluded from the process, which is a dangerous thing. We're missing a lot of insight and innovation. We need to simplify this stuff. We got to do something a little better, keep the good stuff, not throw it out and create a brand new system. Although if you did, you could probably write a book and create certifications and make lots of money, but that's not what we're doing.

(13:31):

We're trying to build legacy systems. We got to come up with a way to simplify this. So you got to throw it all out. We got to keep the good stuff and just make it a little different. So I like to focus on three concepts here, three principles, and we're doing a simplified DDD type approach here. One is thin slices. I mentioned that we have a lot of noise in this process. We want to get to high signal, low noise. So we use a thin slice to narrow our focus, get rid of all that extraneous stuff and help us kind of zoom in on the one thing that we're trying to look at. We want someplace where we can represent these ideas and concepts that we're doing in a way that people understand them. Not super technical, but very representative so people understand, can understand the big picture and contribute where they want to and need to.

(14:18):

And we want some way to test this. We heard yesterday that it's very expensive to build software. Everybody knows that. And it's more beneficial to have a system, even an architecture design that you could test to see if your architecture makes sense before you go build anything. So we want a way that we could test this thing, try to break it to see if our decisions are correct or sort of correct. Good enough, let's put it that way. So let's start with thin slices. A thin slice is something that has a beginning and an end. It could be anything. It could be I want to order some food and it got delivered. I need to a loan, I want to schedule a flight. But it has to be a straight through process. It can't have any if thens in there, right? It has to go straight across.

(14:58):

We're trying to amplify signal, reduce noise. I like to think of it as a bridge. A bridge goes across gaps. There's gaps in functionality. A thin slice is one way over that bridge, over that gap. It reminds me of my automation days where I was doing system controls, machine controls, and I was writing motion control server motion control systems for fluid power, which means that it's a bunch of really big hydraulic cylinders that move up and down to put in weight to assimilate waveform patterns. And I did this for the Lehigh University. It's on the east coast there in their ATLSS Lab, which is advanced technology, large structural system labs. What they do is they test things like bridges and buildings. They build a model of a bridge, bridge beams, bridge pieces, whatever they want. And then they define all these waveform that could be a truck driving across three cars, driving across a dump truck, dumping it, load, whatever they can think of, like a thin slice.

(15:54):

And then they simulate this in the system that we wrote for them, and it shakes the beam. Basically what it does is it breaks stuff in really, really cool ways. So what we've done by doing this in slice approaches, we're simplifying the focus. We're trying to reduce the noise. So how do we find those bridges? We do event storming. I love event storming. I think it's one of the greatest things ever invented. We've done it for so many things. We've done it with a space force to define a giant process to figure out where it would be beneficial to even start working on something. We've used it to design systems. You can do many, many things with it. It's very easy, very easy for people to understand, very collaborative. It gets people who usually aren't ever talking to each other, talking together, which is another piece that's important because again, we want this big system.

(16:42):

We want all the system views. So we go through and event storm is literally just left to right. What's happening? So you put down an event. Events should be past tense, like plane was booked, loan was underwritten, which doesn't make sense, but you get the idea because we're looking for outcomes, not actions, outcomes. And as we're going through this, we see that there's these groups of stickies, there's all this activity happening, and those are capabilities. These are the bridges that we're looking for in the system. Those blue stickies have things that they're doing, they're doing something. And that is a focus area of capability. We call 'em clumps. A clump is a cohesive, logical unit of meaningful process. Now it's actually not. It's literally just literally a clump of stickies. But we were doing this one time for the space force for mapping out one of their systems and someone put their hand up and said, you guys are talking a lot about clumps.

(17:37):

What's a clump? And in a moment of inspiration, I thought about it and I came up with this crazy acronym, and now a clump has a real meeting, but literally it's just a bunch of stickies hanging out together. So what we've done, we're simplifying identifying capabilities and we're simplifying language. Again, remember all those DDD terms are really complicated. So we want to do the exercise. We want to start modeling our architecture, make sure it works. So we take those blue sticky, those capabilities, and we put 'em on our canvas and we pick out some thin slices, some easy ones and some bad ones, something that's good, something that's bad. And then we expand those. I abbreviated here a little bit. It really takes up a lot of space. If we listed out all the words that we want to do in a thin slice, but you get the idea, it's kind of a process.

(18:21):

We start walking through it, and as we start walking through what's happening in this thin slice, we see that these blue stickies need to communicate with each other. They have to talk to each other. The decision needs something from credit reporting. The loan needs something from customer, whatever it is, there's this interaction. People are waiting for information. But now was thinking about a modern system and how the world behaves and the human side of things. People are more event driven, right? We respond to things happening. We don't really always sit and wait for things to happen. So as we're talking through these thin slices, we want to think about do we need to wait for this response or can I just say, Hey, underwriting system, go underwrite this thing. And when you're done, let me know. In those types of scenarios, we put red stickies on there for events, so they're asynchronous, so we're not waiting for 'em.

(19:10):

So what we've done is we've simplified sort of context mapping from the domain-driven design type of concepts. And as we're doing this, you talked about, I mentioned that this blue sticky needs something from that blue sticky. It's a lot of design kind of-ish conversations happening there. What do we do with those? Well, we capture these on these things that we call snappy. And snappy is because it's snap not analysis paralysis. And again, that's another made up acronym. It's literally just snap. But we like making up words for stuff because kind of fun. And it makes a lot of this geeky, not so geeky. So as we're capturing these things, we're talking about APIs, potential APIs, potential data functions and stories that we want. Let me zoom in on one of here, as I can tell you, give you a little more detail on it. Say APIs, we're not writing a fast API spec or a REST API spec.

(19:58):

We're just saying I need this API. When we're talking about data, we're not doing a data schema. We're just saying that this blue sticky is responsible for this hunk of data. That's what we're trying to capture here. We're trying to be it at a logical level that's very inclusive of all people, that every party's part of the system can understand it and contribute to the forward motion of this legacy system. And we're writing things down like the stories, things it needs to do. They're probably more epic level or feature level, whatever flavor of agile you want to use. But they're pretty high level things that these blue stickies, these capabilities need to do in this larger system. So what we've done now is simplifying. We've simplified the implementation details. There's a time and a place to go deep on all this stuff, and people who really know what they're doing will do it.

(20:44):

But we want this logical view, this collaborative canvas that everybody can work from. So how do we get from ideas into action? We can't just design systems. And when I'm saying design systems, this process I'm talking about, this is not months and months and months. We can do this in two days. I've never seen it last more than four or five weeks. When we're building our model, we go through slices until the model stops changing. As we go through a slice, we see that maybe we need a new blue sticky. Maybe there's too many lines going into it. Maybe there's something we didn't think of. We got to split it apart. We got to add some. When the lines stop changing the architecture, the system design is relatively stable. That's when you can stop and start building stuff. So how do we do that? Well, we have all the information.

(21:28):

We have our implementation details. So think of this as kind of like functional programming data in data out, filter, map, produce, something like that if you're into functional programming. But we can turn all that data into whatever you want for the system to be implemented. People like service blueprints, we have all the data. We can make it into service blueprint. If you like more of an outcome oriented backlog, we can generate a story map from the process. The customer I mentioned earlier, they use safe, a scaled Agile framework. They're doing their programming increment this week. And what we did was we generated a big table for them, a kind of like a story map sort of thing with all their dependencies that I just got a slack message with a picture of them actually using that in their programming increment meeting that has, I think 300 people in it.

(22:16):

So that's pretty cool. I thought that was pretty neat. After two days worth of work, we went onsite with them for two days and generated this, and they're using this today, and there's massive programming, increment planning. It's safe, there's safe process. So we simplified planning. So how do we get there? We're talking about legacy systems, and I'm talking about future state and all that's wonderful and happy and fun, but you actually have to, where do you start? Where do you build it? So what we do is we take the legacy system model and we map it on top of the future state model to find out where we can start. You see any opportunities up there on where we could possibly start with this plan? How about this CLS guy? This person's CLS, I'm personifying the function, whatever it is in its current state, is doing a lot of things that we think in our model should be a lot of separate capabilities.

(23:04):

So that's probably a good place to start strangling that functionality out of that cl LS module and start putting into our newer design. So what do we do here? Simplify wise, we're simplifying how to find ways to start in a big system process. So what do you have? Let's recap. We have a simplified process. We have thin slices. They're like wave forms over a bridge. They help us provide focus, they help us exercise the model, and they help us input into planning. The models are architecture model. It's a simple canvas. So we can create logical views so we can pull more people into it. We can test our assumptions on that model. That's very key that we want to be able to have some type of thing that we could stress to make sure our makes sense before we go implement anything. And the main thing we get out of this whole process is we have this common canvas where people who get it, people don't get it, and people get it. Too much can all work together and design a system for the future. So what are we doing? We're like doing the d, DD without all the D, d, D.

(24:04):

Now you saw this. We're expanding some of this process too. What we do is we take some of the information, we export it out to a graph database, if you know what those are. They're very relationship oriented. It helps us to run some more advanced analysis on it. We can look for relationships that we didn't know happen. We can make AI systems and do a vector rag on top of it so we can communicate with our models to do some more interrogation. Kind of really cool type of stuff. Now, you saw our models. There's a lot of lines on there, and I'm up here telling you about you need to increase signal and reduce noise. There's a lot of noise in some of our diagrams as well. So we have some mirror plugins where we can filter the noise out. So if you want to look at a thin slice, you hit this button and only the lines for that thin slice show up there, right?

(24:46):

Again. So we're trying to amplify signal and reduce noise. We've also been working on an ontology, which is when you look at multiple systems, how you can categorize them into each other, what is their lineage type of thing. And this is useful for us because we work with a lot of different types of customers. And whether you believe it or not, many systems, you think your system is unique. They're very, very similar. We were at a customer that does airline software scheduling, and we did a one day session with them, and at the end of the day he said, it's amazing how you guys understand our system so well. It's so unique. I told him it's really not. There's elements there. It's like a loan processing system or a food ordering business. That's what we're doing in the ontology. We're trying to extract all these things that are common.

(25:30):

So as we're doing these things in the future, we have a better way to project into the system of how it is that we want it to behave and how it's good to or better architecture, how it's an efficient architecture. So my main point is don't get too serious about your process. There's lots of good stuff. There's new stuff that's going to be even better. There's old stuff that's still really good. Don't get too hung up on your flavor of agile, your programming language, your design methodology, they all work. It's get everybody working together. Everything changes. Don't get caught in the trap where you're taking a legacy system and just letting it go. If it's core to your system, if a legacy system is main to your process, does great things, start modernizing it. Now, the rewrites are very risky. Oftentimes they don't succeed. Really look for that intent. Get everybody involved on the page. Try to find out what's hidden, what's locked up in that system, right? Try to find out how the system wants to behave. Make it easy to get things done right? That's really what we're trying to get as many perspectives as possible so you can figure out how that system should be. And finally, simplify. Simplify, simplify. Everything can be made simpler. Narrow your focus, make it simpler, and go modernize something. Thank you for your attention.

‍