Ryan Koch (00:01.589)
David, thank you so much for coming on Civic Tech Chat. Could you introduce yourself and tell us a bit about what you do?

David (00:09.048)
For sure. I'm David DeSilva. I'm a principal product manager at Nava. For those who might not be familiar, Nava is a public benefits corporation, and our mission is to help government agencies make their services more simple and effective. At NAVA, I sit on our technology solutions and services team. And I've got a particular focus on legacy modernization. So think about, you know, unemployment insurance, Medicare, state safety net programs, things like that.

our team is really focused on how do we help Nava teams sort of find the reusable playbooks, assets, artifacts, those types of things, when they're starting off on a modernization effort. So really focused on kind of learning and and redeveloping.

Ryan Koch (00:58.624)
And what would you say is your personal why? That thing that drives you to get out of bed each morning and do what you do?

David (01:05.164)
Yeah, for for me it's really about improving the way that the public interacts with government. So, you know, we think about obviously a lot of cases around sort of benefits or receiving benefits, but there are a lot of interactions that go beyond that, whether it's you know like a healthcare or hospital quality reporting, which is like another project that a team works on. and so I think it's really interesting because those challenges work across a number of levels. You have technology, people, policy.

and and ultimately for me, like it's those interactions and the quality of those interactions that lead, I think, to like higher trust and confidence in government. So that's for me really the the so what and and w and why I'm interested in this space.

Ryan Koch (01:49.855)
That statement you made about the quality of the interaction, having a relationship to folks trusting government, is interesting. It sounds like very personal thesis. what inspired you to kinda land there?

David (02:02.508)
I for me it's it's I think a couple there's a couple there's a couple like personal reasons, and there's some there's a like a macro reason in there too. You know, on on the personal level, it's I a lot with like my own just interactions with government, right, as as a citizen. and I think of like family interactions with government. I was talking with my dad, this actually happened like a few weeks ago where you know he was trying to get in touch with someone at Social Security for help with his benefits, right? And he had a really positive interaction and that led to

A really much more positive sort of like thinking about that agency and the and the mission in the space. And so at that level, and then I think about some of the macro things, like almost like it's kind of like a silly example. But if you've ever seen the movie Zootopia, there's a moment there where they're at the DMV and and they represent that interaction with sloth, right? And and it it I think speaks to a really like specific kind of

Ryan Koch (02:48.605)
Mm.

David (02:58.84)
perception of government right in the public and w which which is unfortunate and I and I think could be improved and and and create a a positive cycle there. So so yeah, so so some very personal things, but also just sort of seeing kind of like the the general cultural like discussion, right, around interacting with government.

Ryan Koch (03:18.256)
Folks that have been looking at the episode description already before they hear us might have already spotted this legacy lockpicks term. When we use that in our conversation today, what are we referring to?

David (03:32.375)
Yeah. So you know, NAFA's definition of a lockpick in in this case is really like a reusable tool, a reusable playbook, a framework, a process, basically anything that's going to help a team transition, you know, out of a legacy system either more quickly or or with less risk. you know, we kind of use that lockpicks term somewhat intentionally here. So the I, you know, the idea is not that you just want to get

rid necessarily of everything in that legacy system. There's a lot of a lot of value that's built up in those systems. But either maybe because the system is super brittle or there's or there's some sort of like vendor entanglement, it can be hard to access that. And so that's where that sort of like lockpick metaphor kind of comes in. And as I kind of touched on, like it can be like these can look and feel very different based on like the particular challenge that we're facing on on any particular project. Right. So it might be a tool that helps

teams sort of compare the outputs of a legacy system to a new system. It might be a tool that helps, you know, convert policy into requirements. the the point really is that we want to find the reusable assets, the reusable ideas, right, that again help teams from having to reinvent the wheel whenever they're engaging these problems on a on a modernization.

Ryan Koch (04:55.214)
The part of my brain that, you know, comes from that software background, loves the concept of things that are reusable, right? I think that that usually brings a lot of good to projects. What's an example of one of these lockpicks that you've experienced and seen succeed in being reusable like that?

David (05:12.608)
Yeah, that's a that's a great question. I think so, you know, when we talk about reusable here, like the example I'm gonna give is around actually like change I'll I'll sort of c cite change data capture and data replication as as a form of a lockpick. Now, is it is it is everything a hundred percent usable around that? No, like every right, every time you use that that approach, right, you have to sort of have things around the edges that fit to that specific, you know, particular system that you're working with.

But at the end of the day, like why I kind of give that as an example is like when you've got two systems that you're trying to maintain in parallel, you have to keep those in sync, right? And if you if you can't sort of figure that out, if you can't lockpick that data, then you're gonna be stuck. And so I think that's a great example of a pattern or an approach that teams can reuse that you know greatly de-risks a lot of modernization efforts.

Ryan Koch (06:06.797)
How does this concept of legacy lockpicks reflect on and fit in with the the broader approach that you take to the work?

David (06:15.18)
Yeah. So, you know, LockPix kind of really fits in a lot with the underlying sort of like NAVA principles around open architecture. So the idea of like we want to help agencies build systems out of modular components that are easy to evolve over time, right? And sort of avoid that kind of like slide back into lock-in. So that that's I think really connected to why we launched Strata last year.

as Nava, right? Because those are those are those sort of predefined standard open architecture components that agencies can kind of build their systems with. and so for Lockpicks at the end the day, this is about sort of connecting into delivery, right? So we had to take that kind of like high-level strategy, right? and kind of like push that into delivery so that teams are able to kind of embed that on their day-to-day work.

Ryan Koch (07:14.389)
You mentioned strata as as one of those kind of examples of an of an open architecture thing that y'all have latched on to for use. for folks that maybe haven't seen our prior episode, where we kind of do a little bit of a deep dive into what it is, what it's about, what are some things that Strata might get used for, kind of like in in early days that would help accelerate a project?

David (07:36.759)
Yeah, so I think a good example of that is is some of the work we actually did with Minnesota PFML. So that was a a new system that got stood up recently in the state of Minnesota in our work with them. and so f the way that Strata kind of got involved with that is that is was in two ways. So one is that there's sort of a base application inside of Strata that we are able to to leverage. And then two, there are a set of infrastructure templates that allowed

you know, the the team to spin spin up and and deploy those d deploy that new application, you know, in a matter of of weeks. So in particular, like that s accelerated that early stage of just getting something into production so that we could then have that positive momentum. I think at the end of the day something like we estimated save something like seventeen weeks over the course of that. So that I that I think is a a a pretty good example of where, you know, something like Strata can help accelerate the overall

you know, delivery motion.

Ryan Koch (08:36.787)
And to get to that seven teek weeks, what do you think is like the primary saver activity? Is it kind of like decisions that you don't have to make because they're like a pi like the thing is opinionated? Is it the infrastructure itself, the setup that's easier? where do you kind of see the the most value coming out of that?

David (08:53.612)
I it, you know, I I think it's there's probably not any like single layer where that comes in and and delivers value to the team. I think certainly, you know, it saves in in my opinion, it saves a lot of kind of like the repeat effort, right? So in terms of like deploying infrastructure, right, we can have that ready to go. You can have that infrastructure as code and then it, you know, it's about sort of like clicking a button as opposed to kind of rewriting that from scratch every time.

I think similar with at the component level then too for the actual application, right? So you so we've got ways to make it easier to build those forms as an example there. again, just so teams don't, you know, keep teams can start at sort of like the eighty percent mark as opposed to having to start at the zero, you know, at the at the complete like blank, blank page or blank screen.

Ryan Koch (09:43.441)
Often technology is not the most significant bottleneck for this kind of work. There's organizational challenges to surmount like change management, the need to shift policies and practices, gaining trust and credibility to push work ahead. Of these threads, which one do you find yourself spending the most energy on? And what's an approach to address it that's worked for you?

David (10:07.224)
So for me, it all comes down to trust, especially in in legacy modernization. So if if you don't have that trust, I really think it's only a matter of time until, you know, the politics of the organization catch up with you or, you know, the resources that were initially sort of dedicated to your efforts start to get pulled, you know, off to other engagements or get pulled onto the shiny new object, right?

and so that that trust factor, I think, also really works across like all of the layers that you just mentioned that are part of these holistic modernization efforts. and so for us, a lot of our focus is therefore then on like how do we really help teams get off to faster starts? if you think about, you know, the start of a start of a big project, right? there's gonna be a lot of there's gonna be a lot of goodwill usually, there's gonna be a lot of excitement, there's gonna be a lot of energy.

And so it becomes really important to convert all of that into forward momentum so you can start to demonstrate the value that that team is going to be able to deliver. And so one like clicking clicking on this like a little bit further down, you know, one of the areas that we're spending a lot of time exploring is is like how do we compress the amount of time that teams spend in this discovery phase or like often referred to as like archaeology phase, right?

So by compressing that up time, because we still have to do those activities, right? We still have to understand what's happening in the current system. But if we can compress the amount of time that teams spend doing that archaeology, we can really allow them to focus on much higher leverage, higher value work. And so that's I think a key way to kind of build that that trust that we're talking about.

the other the other layer that we think about is around and this this starts to get a little bit more into like back into the technology layer, but I think it's important, kind of worth calling out, but around the the data layer itself. So talked to a few folks in the last couple of weeks who sort of cited examples of modernization efforts that like completely stalled and died because

David (12:18.852)
not because they couldn't figure out the logic, not because they couldn't, you know, rewrite the application, but because ultimately they couldn't migrate the data out of their legacy system. And so they just sort of you know, ended up wasting like a couple of years of effort. So for us, again, it's a lot about thinking about like, okay, what is what is the existing shape of that legacy data? Like what do you have today? And then how do you understand kind of like what that future state model is and how do you how do you connect those two?

when we talk about patterns like Strangler Fig Two and you know, I mentioned a second ago about sort of like running systems in parallel and being able to sort of de-risk efforts by doing that, that also becomes like really dependent on like being able to manage that and unlock that data layer. and so, you know, for those reasons too, I I I see that as like a really kind of like key aspect of a successful monetization effort.

Ryan Koch (13:14.475)
On the the first layer of your answer, I heard you talking a lot about trying to compress time from like a certain level of value activities up to the next one. And I I presume maybe even think about that like stepping up. And it almost sounds to me like there's this almost like a timer that a team has, like to put something in a real person's hand lest patients run out with a project. Is that is that s pressure I'm kind of sensing from your description there and something you're seeing?

With teams and this kind of work.

David (13:43.725)
Yeah. Yeah, I I I I think that's I think that's absolutely right. Like, you know, I think the you know, these modernization efforts are like high, high investment, right? There is there is typically like very high cost with these projects, right? There's a lot of typical like typically like the sponsors of these projects are spending a great deal of of like organizational, like their own organizational capital, right, to to get these projects approved. and so so yeah, I think there's there's you know, it's just it's just human nature to want to

be able to show kind of quickly, right, that you're able to deliver deliver value, right? And show that you're kind of on the right track.

Ryan Koch (14:24.725)
And on the the data layer, you mentioned a couple of different examples of modernization effort styles. have you se have you seen any in your lived experience that either like went really well or or not so much that attempted to in that particularly in that data layer problem?

David (14:42.816)
Yeah, so you know, I think there are

Actually, can we can you can you ask that question again? Sorry.

Ryan Koch (14:52.244)
Yeah, yeah, yeah, sure. I can maybe that was like worded a little funny. I'll step back. with the data layer part of your answer, you talked about how data can get stuck and how that impacts the modernization method you're using. I'm curious if in your lived experience, if you've kind of gone through a project there where it either you know got stuck and was a problem, or a situation where it happened to work out quite well because you managed to work past that.

David (15:19.532)
Yeah. So one one of the one of the projects at Nava that I think has been, I think really interesting for me to like kind of like learn from and see what they're doing at the data layer is some of the work that we've been doing at CMS around like data monetization. And so, you know, there's a mainframe system there and and in that case, right, there's really no desire to get off the mainframe, at least anytime kind of soon. but there's a lot of value that can kind of be unlocked by

by essentially like replicating that data out to the cloud so that other like newer applications can consume it. And so I think it's a really great ex example of of a way to modernize that isn't necessarily, you know, we have to deprecate this mainframe, but but really being intentional about how to unlock value from what's there and and kind of strike the right balance between, you know, what's the appetite for risk versus what do we need from like the needs of of the business. so so yeah, that I would point to that as like I think really a

good example around modernizing that that data layer.

Ryan Koch (16:22.248)
It it sounds like kind of the success there is not replacing the mainframe, but kinda adding like a another level of abstraction so that if you want to later, you're already relying on these other things in the cloud. It's just the way the the data gets to those would have to change in order for you to reach that step.

David (16:40.986)
Right. Yeah, exactly. Right. So so, you know, I think, you know, it's it's been interesting in the space around, particularly around like, you know, when you s when typically right when when someone mentions legacy modernization, most people think immediately about the mainframe, right? And like sort of that's kind of, you know, the only thing that people think about. but you know, I think there's a lot of, you know, if you dig into like the chatter in the space, like there's there are a lot of folks that are out there saying, like, well,

One of the reasons that mainframe is still with us because it it's really good at a lot of things that it does, right? And so being, I think, intentional about where where does this technology work for us, right? Where does it not work for us? And then using that to inform like how you modernize is I think I I think kind of key and like I think underline some of the points that you're making there.

Ryan Koch (17:30.748)
These projects ultimately exist to serve people. we're talking Medicare beneficiaries, claimants, families navigating, social safety net programs. and a lot of the daily work is about wrangling stakeholders, contracts, old code bases. when you're kind of in the middle, in the bubble of all of that, how do you keep those end users that we're thinking about present in the room with you?

David (17:56.247)
Yeah, yeah. so I you know, for us, I think the the the goal is to keep end users kind of in like like present throughout that entire process. So, you know, you know, human centered design is is a major tenet of NAVA's approach, right? And and so one of the ways that we do that is not just have you know kind of like research be an input at the kickoff that you sort of, you know.

use once or refer to once and then you move on. But right, the goal is to kind of continually pull that into our our our sprint cadence and be able to pull that into decisions as we go. I think the other thing about this is is, you know, not designing in a vacuum, right? So I think it's one thing to sort of, you know, think about design as like what is what is the most elegant design versus like a a more maybe again like maybe to overuse the term human centeredness here, right? But

To be more grounded in sort of like what's what's the real world experience going to be around this, right? If someone's filling out benefits and they're trying to do this at 11 o'clock on a Sunday, they're going to be in a very specific sort of mode, right? To try to get that work done. And so how do we, how do we think about what does it mean to design for that specific type of of interaction? like to also connect it to something that we were talking about a a minute or two ago, right? And you know, I was talking about like compressing.

compressing discovery, right? Compressing like the archaeology phases of of these modernization efforts. And this is a big reason to me why it's important to do that, because teams spend so much time thinking about or trying to understand like what was this system designed to do 40 years ago. And then they they miss the opportunity or they run out of time to actually think about like, well, how should this actually work going forward? Right. And so

G th again, like the the less time that we spend sort of unpacking the past, the more time we can think about what's the right way to have this service exist going forward.

Ryan Koch (19:56.791)
I like the connection you're making back to that because you also in your answer talk about this being like an ever present thing in the process. Like the research step isn't just like, all right, I tested with some users, I'm done. You know, their the nature of their circumstances change. The technology they uses change, the systems and policies change, like you need to be constantly. And you mentioned there at the end like that that goal to try to design something that works for them. Well it's like really hard to learn enough to do that if they can't

Touch it. Right. So like as you talk about compressing time, it seems like these ideas connect together to again getting that place where it's like, hey, can I get this to a person's hands so I can learn if it's any good at all and if it's useful?

David (20:40.846)
Yeah, yeah, absolutely. I I, you know, the the whole idea of like shipping, and it's it's also partly why it's important to ship early, right? Not only you building trust with, you know, we talked about building trust with stakeholders, right? And and showing positive direction and positive momentum. it it is also, of course, to still like validate that what you're building is actually working for your intended users.

Ryan Koch (21:10.349)
Caseworkers and program staff who use these systems often hold deep institutional knowledge that it might not be written down in documentation. how do you make sure to engage them in the work and how do you handle it when their look workflow expectations have some conflict with what the opinion is that the modernized system of what like what it should do?

David (21:33.005)
Yeah. Yeah. So caseworkers are like a a tremendous source of insight, right, in terms of how systems actually work. So, you know, you could have written documentation, you could have written policy, but oftentimes right, that can kind of drift from what's actually there. And so caseworkers are are are great at at understanding that reality. And so because of that, right, we want to treat them as, you know, co as co-designers really, not just sort of like passive stakeholders.

And so by incorporating them into our design, I think the other element here is like, you know, we've we've been talking a lot about like redesigning experiences for beneficiaries, right? We want to experience like change how services are delivered. But a lot of our work is actually about how do we reduce the burden for caseworkers themselves, right? How do we make it easy to process a case? because if we can do that, then we can make, you know, processing times for the for the end beneficiary go down.

And so in that case, it's really thinking about those caseworkers, you know, not just as like information sources, but actual users that we want to be able to design around. in that case, you know, there's like you get into like some of the change manager stuff that we talked about, right? Where caseworkers as an example, right, can have like very specific ways of working and and like their their processes and their ways of working can sort of grow around the legacy system. And so when we're thinking about how should this thing

change or behave going forward, right? We want to be really intentional about okay, what's the what's the why behind there? And is it something that actually you know, is is a preference that like we can sort of change because there's a better way to do it. Or it's actually, no, this is actually a like a hard requirement. We have we have to keep doing it this way for some you know specific reason. so you know at the end of the day, it's like just as we want to be intentional with the experience that we're creating for end users, we want to be intentional about the experience that we're creating for

caseworkers and and other internal staff.

Ryan Koch (23:37.022)
What's the time when you saw the direction or design shift after you kind of discovered something as you were working with caseworkers and learning about their workflow?

David (23:48.419)
So I think I think I think kind of riffing off that, I think there's a recent example actually from some of the Naval Labs work that that kind of fits in well here. So Naval Labs was recently working with Maryland around sort of snap work requirements, right? And all those changes that are coming up. And so, you know, as as part of that, there have been sort of like the typical ways that a beneficiary would sort of submit their documentation, right? and Novel Labs was sort of

Or not sort of, they were piloting a new way to do that, leveraging OCR and AI to like essentially like improve the quality of the images that were coming in, because that's a there's a key pain point in that overall process. Right. And so I think that's I I think this is a great example of like one of those tensions where the the stated process is that there are, you know, require there are, you know, requirements to gather certain documentation or certain evidence. And we want obviously work within that overall.

requirement, but then there are going to be like different ways that we can innovate within that space. Right. And so pre like creating this new pathway through document AI kind of allowed allowed that sort of like slight process shift that still worked within the overall like end-to-end goal that the agency had. So I think I think I would like point to that as a as an example there.

Ryan Koch (25:08.805)
In that example sounds like there's was potentially the possibility of having some like stakeholder conflict between caseworkers and beneficiaries in this case, which are kind of like a different coming from different perspectives. Is that something you ran into and if so, how did you try to navigate that?

David (25:27.34)
Yeah, that's a great question, Ryan. I I wasn't on that project so much day to day, so I I don't have, you know, I think first hand view of the stakeholder dynamics, but it it totally I think a fair a fair flag and and question ask.

Ryan Koch (25:41.351)
I guess if not that project then one that you have that lived experience in, is that something you've run into where it's kinda like two very different like maybe folks kind of on two sides of an application running into conflict, are there strategies that you kind of have seen successful for that kind of conflict resolution?

David (25:58.477)
Yeah, I think I think in that case, like it it gets back to kind of like the research, right? And that we were kind of talking about a little bit before. So, you know, the like being able to actually also sort of hearkening back to what we were talking about with sort of like change management, sort of like the non technical aspects of a lot of this work is like it's it's it's natural for people to not want to change. It's natural for people to be kind of like

used to the way that they're working and want to be able to keep that. And so I think the way forward through that challenge, right? Like what you're talking about, where there is that sort of like tension or conflict is like, is, is not about the technology, right? It's about like the more of like the just working, like how do you build and work through this as like, as like humans, as a team. And I think to that extent, like it comes down to like,

showing like true like empathy for the people that you're trying to serve, right? And like true and like trying to get to like a true understanding of like what is it that they're doing. And so if you can do that and then if you can reflect that back to people and show them that yes, you are listening. Yes, we hear you, but also help them understand with like a fairly rational case about w why things have to move forward. I think most of the time you can find that right compromise for folks and nav you know navigate the right path forward between those tensions.

Ryan Koch (27:24.751)
We've talked a bit so far around different ways that patterns for approaching legacy modernization can kind of come into the work. what sort of legacy patterns do you tend to favor with with your client work?

David (27:38.393)
Sure. So patterns wise, you know, I I think when people think about legacy modernization, they tend to think about like re re, you know, generally rebuilding is a is a major pattern that comes up. And within that, like strangler fig seems to be the one that like almost everybody can, you know, name, right? Which I think is this interesting data point. you know, the the the whole idea behind that strangler fig approach, right, is that you have some sort of like front door or facade that you put up.

so that you can essentially keep the user experience consistent while you kind of migrate or you know, modernize behind the scenes more incrementally. you know, to to use like a little bit maybe more of like a non-technical metaphor just to you know, this concept is so prevalent, I think it's worth like spending a second on, but to maybe have like a non-technical metaphor to kind of walk it through. you know, imagine you were eating at like a very small restaurant where there was only one person working there, right?

and so they're, you know, they're gonna greet you at the door, they're gonna sit you down, they're gonna take your order, they're gonna go cook it, they're gonna bring it back to you. If that person hits the end of their shift and they need to, you know, switch out, like it's gonna be a very disruptive experience for you as a diner, right? now, like that's a very fictitious example. But if you contrast that with like a more typical dining approach, right, or you know, situation where you have like a waiter who's sort of they're they're now there to sort of like,

create that continuity for you, right? Create that same experience. that's that's the facade. That's the front door that we're talking about in that strangler fig approach. So so in that case, right, if the entire kitchen staff turns over during the course of your meal, like you're you shouldn't really know, you should never notice and you shouldn't really care, right? At the end of day, because like your experience is not being disrupted, right? because of of that waiter. So

That's what we're trying to do. Like, you know, that metaphor isn't perfect, but you know, hopefully helps. And like that's basically what we're trying to do with Strangler Fig there, right? now once you have inside of that pattern, there are I think lots of other things that you can start to do around like comparison testing and behavioral testing to make sure that systems are actually getting to the same sort of outputs. so I think a lot of interesting like things, like a like a click down from there. stepping back out, like there are other patterns.

David (30:02.498)
that folks can name like lift and shift. right. That's you know, for me, like as we talk about a lot about like AI approaches, I think a lot of a lot of those AI-driven approaches to modernization sort of like tend towards this side of the spectrum. another one is kind of leave-in-layer, which is in this case an idea that you you don't need to get fully off of the legacy system, but you're gonna sort of build around it.

and then a version of that is is actually what we were talking about a few minutes ago with with data replication and data modernization. The idea that, you know, we're going to leave the existing system of record, but we're going to find a way to make that data available so that new applications kind of consume it and create experiences around it. So those are those are a couple of different examples, I think, that we've seen firsthand. ultimately at the end of the day, like the right pattern is going to come down to.

whatever the specific like business need is right for that agency. and and based on that you can kind of choose the pattern that kind of best best fits their purpose.

Ryan Koch (31:07.444)
I hear you making a strong connection in your answer between the lift and shift pattern and AI kind of tooling and techniques in used in modernization approaches. to hear you say that to you are they kind of of like becoming one and the same it's just it's lift and shift just new tools. or or is it maybe a bit different than that? Yeah.

David (31:24.558)
Yeah, I I I I I mean you're right. I did I did associate those. So I I when I say that like AI, a lot of these AI approaches are are like lift and shift, I don't mean it I guess I don't mean it in like the strict definition of lift and shift of like, you know, the the re-host, like we're not going to touch anything. we're just gonna, you know, take it on-prem and drop it into the cloud. Like that that's a very like strict interpretation of lift and shift. What I'm more trying to convey, I think, is that these approaches

They're not really trying to like for the most part, like reimagine or rethink what this system should do going forward. They're very they're very much about like, we're gonna take what's here now, we're gonna try and we're gonna try to move it as quickly as we can to some sort of future state. And then we're gonna iterate from there, right? and so I think that that that to me is why I kind of like put it more on that side of the spectrum. but

Yeah, there are sort of wrinkles inside of like, okay, is it a re host? Is it a re platform, et cetera? which is like a fair a fair call out there, yeah.

Ryan Koch (32:32.219)
you talked at length with that metaphor on Strangler Fig, and it's actually one that we've covered a bit in a prior podcast episode, which I'll also link in the description for folks if they want to do some additional diving there. as as you think about that method and your own personal experience with it, what's an example where that's either like worked out really great or one where maybe it didn't work out so great and that experience really stuck with you? And what was kind of like the lesson you picked up?

David (33:02.774)
Yeah. So I think from a I think from a modernization standpoint, like Strangler Fig, it really works well when there are kind of like I would say like three, there kind of need to be three criteria in place for it to kind of work really well. So one, you know, it's gotta be a a fairly large system because like you kind of know that you're not gonna be able to

Just rip it in one go, right? It's it's big enough that you're like, okay, we need we need to kind of like chunk this up. two, it's also a system that you know you need to get off of for whatever reason, right? So we talked about like the leave and replace where like it's just like, you what, we're gonna innovate around this. Like if if you're doing strangler fig, like your goal has to be like, we're gonna get off of this system. And then three, you have to be able to sort of find like seams or like, you know, clear, clear places where you can sort of like,

incrementally pull logic and processing out of that legacy system. So if you've got those three things, I think then it'll work like pretty well, right? And I think we've seen one of the one of the projects that we're working on now, like essentially like kind of like built the like new application portal. And then essentially that became the facade, that front door, right? And then they were able to start kind of like working behind it. And so I think that it works really well.

I think we've seen other examples or like even like inherited other examples, right? Where you start that process, but you never actually get off of the legacy system. And so now you're in now you're in a much worse spot where you're kind of like you've got two systems and you're trying to straddle them and some some you know some your your system of record is partially in the mainframe, you're and partially in this new system. That and that becomes really that becomes really, really messy. and so I think that's where, you know, we certainly don't want to get stuck in that position.

but if you've ever worked in that, like those types of environments, like that that becomes like a very difficult situation to kind of work out of.

Ryan Koch (35:07.843)
I I think I'm hearing like a a little like hidden constraint slash requirement to Strangler Fig, particularly where it's like you need to have not just political will for the project, but over like the long haul. Like there's needs to be some amount of like continuity from you know, program policy coming down that this project's important and this method is what we're what we're doing, it we're committed.

David (35:30.125)
Yeah, absolutely. I think that's that's totally right. Because like, you know, if if almost by definition, if you're employing the strangler fig pattern, right, like you're dealing with some kind of like long running modernization effort. so yes, like absolutely need that sort of like top down, top down buy in. And then, but it's also what we talked about again, like so much of this conversation today has been about trust, right? And like what do teams do, like a non technical perspective, but like

Teams also need to sustain that energy, right? And they sustain that energy by delivering. so that like that it it's it's both, right? Like both both sides of that of that spectrum need to be able to to kind of keep keep the buy and keep the the willpower to keep going.

Ryan Koch (36:18.84)
How can we use solid practices to ensure we get a a return value on our investment early in the work rather than waiting all the way to the the tail end? And how does that affect our approach to risk management?

David (36:32.834)
Yep. Yeah. Yeah. So, you know, we've been talking a lot about this today. I think so, you know, we've talked about I think the momentum parts of this challenge, right? So like thinking about what's something that we can actually ship to production that's going to create value for a beneficiary, for a caseworker. you know, we we think a lot about it in terms of like, you know, not just shipping or not shipping, but we don't just think about like prototypes or demos, right? But we want to actually have working software in production.

And so okay, we talked a lot about the momentum. I think the other sort of piece here that we haven't yet talked about is that like shipping to production does a double duty of creating that value, but also de-risking the longer term because like you essentially shrink the unknowns that you're dealing with, right? So just by that act of trying to get production, you learn a lot about the system. You learn about also like non-functional requirements that can often be a drag on these efforts, whether they're security, ATO, right?

compliance. And so by kind of getting into that pattern early of shipping, you know, to production, you can really, I think, de-risk these efforts because you just learn more and more about what you're dealing with at the end of the day.

Ryan Koch (37:54.411)
I imagine a a lot of the work we're we've been talking about today involves some parsing between decisions that are easy to undo and those that are much harder or maybe even impossible to pull back. how does that influence the way you tend to approach these modernization projects?

David (38:11.874)
Yeah, I so I I really like the language around two-way doors and one way doors as sort of like a framework for thinking about these decisions. two so two way doors are ones that you can essentially kind of like walk through and then and then walk back through if if needed, right? And so those types of decisions are really, you know, should be cheap and easy to change. in that case, like for those types of decisions, right, you want to be like

Pretty quick in making that decision, ship something and then see what the data says, right? So, you know, thinking about like A-B experiments or other just data-driven decision making. I think contrasting this with one-way doors, which is, you know, these are gonna be decisions like like, for example, like a data model, where, you know, changing that later is going to be pretty painful and costly to the team. and so in those cases, you wanna kind of

You do want to spend a little bit more time up front doing that analysis. Maybe it's a spec or a spike, right? To get more information. build, you know, get get to that understanding and then make that decision. So that, you know, the the biggest sort of kind of trap in all this is just you know, not understanding which decisions are one way or two-way doors, right? And but if you can get that right, I think you can really move through these decisions like much more, much more rapidly and much more effectively.

Ryan Koch (39:39.593)
I hear maybe a a little bit of like a shared worry between kind of the answer in this question is also the one we talked about earlier about data getting stuck when you're kinda talking about the the data layer. are the kind of the worries about one way decisions and kind of data getting stuck kind of coming from the same place?

David (39:57.463)
Yeah, yeah, absolutely. I I I think, you know, that like the examples that we talked about, right, where, you know, the modernization efforts kind of completely stalled out because that data was was locked in, I think is a perfect example of this, where like the team, you know, should have spent more time kind of up front thinking through what that strategy is going to be so that then when they get to the end, they actually have a path forward. so yeah, I think that's a perfect example of like you can't, you know, some of these things you can't defer to the end because you you're

Just you you paint yourself into a corner and then you get stuck.

Ryan Koch (40:31.76)
And something I I think you mentioned that's rather important is you you can't treat every decision like a like a one way door, right? So some of them have to be two way doors and and treat it as such. And I imagine in the product space, having to try to facilitate identifying those and then agreement that, hey, this one actually is a two way door and here's how we're gonna control for that is maybe a challenge. what's your personal experience been like trying to navigate that kind of conversation?

David (41:00.706)
Yeah, I I think, you know, in some cases you can sort of use the, you know, with some teams, you can sort of use the two-way door like terminology explicitly, right? You could like and like you could even think about like that being a a mental model that the team shares. I think, you know, for teams that I've worked with, it you know, I don't necessarily use like I don't necessarily call something a two-way door, but it'll it'll I focus more of my language and like the team around like experimentation or data, right? And so if they're

You know, a common question that I'll ask is like, what what's a, you know, what's a quick experiment that we can run here? And if the if the if they come back pretty quickly and be like, yeah, we can go run this experiment, like great, like let's go do that. And then and then we'll make then we can make a decision, right? So I think it's just framing like it's a lot of the framing around it as like an experiment, I think is like basically if if you can structure it as an experiment, it's probably a two-way door. You're probably pretty, pretty safe.

Ryan Koch (41:59.577)
AI tooling has been showing up in our space in a few different ways now from helping translate policy into testable rules to assisting with code understanding with legacy systems. Where are you finding it genuinely useful for modernization work and where do you think it's more like hype machine kind of stuff?

David (42:20.982)
Yeah, yeah. So, you know, I think for us where we've seen it is like specific like particularly around like trying to understand legacy systems and getting your arms around it, like certainly is has been like very valuable there, right? So it's you know, these tools are able to either generate diagrams, dependency maps, especially in situations right where like the original developers are long gone, there's maybe only a handful of folks that have any context on what the system actually does.

Like that, that is, that is truly valuable. I think and you know, adjacent to that is some of the like the like documentation generation that you can do with that. So you know, helping teams like rebuild that knowledge base because again, oftentimes like it's it's not there, or if it is there, it's it's really stale. one area that we've been experimenting quite a bit with is around like thinking about how to go from like

policy to actual like working software and like compressing the amount of time that teams spend kind of like typically in that in that sort of like translation. So I think I think that is like something that we're hopeful. You could also imagine, you know, inside of policy there are all sorts of like processes or procedures that are defined for these systems. And so trying to like quickly understand and unpack those. One, you know, you mentioned the like hype hype cycle around this stuff.

I I will say I'm I am personally a little skeptical that like right now, at least you're gonna point an AI at a legacy system and just sort of magically get magically get that modernized system out on the other end. Like I just I don't think that's where these technologies really are yet at the end of the day. and like for all the other reasons that we talked about too, which is like it's like

Modernization is is is about more than just the technology layer, right? There's all the change management, there's all the process changes, there's the policy changes. And so it's like once you even think about these efforts like as like holistically as they are, like the the AI layer is just one is just one one component of that. I think the last thing I'll say on this is that like, you know, AI is such a it's such a compelling general purpose technology, right? Like

David (44:39.808)
It you know, it, you I we started the call earlier, talked about like change data capture. Like that's a very specific technology that you use in a very specific time for like a very specific problem that you're having. but AI is is like the exact opposite. And so it creates a lot of noise and a lot of like, you know, a lot of fog about like where can it actually be used, right? And so one of the things that we're trying to do as as like our team in the space is to really be

I I think like honest about like where are we where are we trying these tools? And then where are they where are they valuable and and where are they not? Right. At the end of the day. and so I think, you know, what we're learning is that like at least where these tools are right now, like you have to have a human in the loop. You gotta you have to have someone there to make sure that it's kind of staying, staying on the rails. but overall, like, you know, like I said, like our goal is just we want to, we wanna.

be transparent about kind of what we're learning as as we go on this journey.

Ryan Koch (45:39.977)
At the end there, you mentioned this need for humans in the loop, which I think is a phrase folks hear a lot. but in your mental model of that, where do you tend to see the human kind of fitting along that loop?

David (45:53.357)
Yeah. So I think we there are, you know, so far I think we've there are two areas where we've, I think, seen the most value. So one is in sort of the like creating the mental model or the structure for the AI to explore a given space. And so what do I mean by that? I mentioned this example that we've been playing around with with like policy as code. and so one of the like one of the early like

examples of human in the loop that we had is like is like a policy strategist who would essentially like give the give the LLM some structure for like how to think through a given policy area. Right. And so like with that structure, we could improve the accuracy that of what the LLM was doing. So it's sort of like that upfront kind of like guardrails or guidance. and then the second is I I think as I think folks are like like a lot of folks already into it is around evaluations, right? Just like

being there to understand like, okay, this is this output actually does this output actually make sense, right? Like and and all the judge all of the judgment that goes along with that. So that's those are the two areas that we've been kind of like most plugging in humans in the loop in our in our product development.

Ryan Koch (47:07.377)
And earlier in your answer, you mentioned the use case of documentation generation. And it's something it made me think about is on the software end, there's all these like open source projects, right? And sometimes what can happen if it's a p particular if it's a popular one, is folks really want to help their favorite project out, right? So maybe they like kick up their favorite LM, they prompt it, they feed it context, comes up with maybe a an excellent PR, or maybe not, you know, it depends on how well was prompted probably.

but then that happens once, twice, a hundred times. meanwhile the team that's managing the project maybe doesn't there's like three of them, you know, and they're volunteering their time on the side while they're working a job or you know. And i it's that it's that thing where it's like at some point is there a risk that the bandwidth to review gets overwhelmed by the the generation of stuff? Is is that something you you see and think about?

David (48:02.134)
Yeah, I so I mean that's that is a that is a huge challenge. I don't I don't think we I don't think I have the answer to your problem yet because like I think we're see also seeing that firsthand in some of these tools where they they create so much documentation and so much analysis that like there's real effort to get teams just to sort of be able to digest all of this, you know, information that it's producing and then let alone like assess whether or not it's accurate. So

I think that's that's a huge point. I think some of the things that we think about as like mitigations around this. So one is a lot around like the testing and an evaluation stage. And when I say evaluations here, I don't mean in the sort of like the LM as judge kind of idea of evaluations, but more about like actual like deterministic, like more like test-driven development evaluations. So early on we talked about like comparing system behavior. and I think like

where we can get to sort of like that type of guardrails, like that can I think be an interesting check on on some some of this problem that you're talking about. the other thing, the other thing that we're thinking about, which somewhat related to what you're talking about, again, doesn't like exactly solve it. but we are thinking about sort of like through our development process as we're sort of using, you know, more AI tools in our development process, how are we making sure that like the documentation essentially like

is updated as we go. So that there isn't like part of the reason part of the challenge of why there's this big influx of documentation that you talked about is because like so much has gotten out of date over time because it's it's hard to keep up with, right? And so the more that we can sort of bake that in. And we were working on a I was working on a tool with a couple engineers just the other day and we're changing sort of how one of the endpoints functioned, right? and now those all those endpoint changes like automatically get updated into all of our API documentation.

It's I think a great way to like reduce some of that burden over time. even if it doesn't sort of like solve that like catch up problem that you were kind of talking about there.

Ryan Koch (50:07.331)
And David, as we get kind of towards the the tail end here, you know, we've covered a lot of ground today. We've covered, you know, reasonable lockpicks as a concept. We've talked monetization strategies, you know, good, bad, indifferent, you know, and all of those. We've talked about where AI can fit in some of these things. If there is, you know, one or two things that you hope folks listening to this kind of keep with them in their day or beyond, what are you hoping those are?

David (50:34.114)
That's a good question. So I I I think with anything, you know, we and we've this has been a theme throughout our conversation, but especially in legacy monization, I think it's really worth like you know, reemphasizing, right? Is that you know these efforts are about more than technology, like especially in the government space. you're dealing with policy layers, you're dealing with like organizational issues, right? Yes, you're still you are dealing with technology, you're dealing with processes.

and so, you know, to think about legacy modernization really is like holistically across those dimensions and not not it's not just about, you know, going from like on-prem to the cloud, right? so I I I think that's one. and then I think the other is you know, thinking about like I think be just being intentional about these AI tools and and being intentional about where to deploy them and thinking about where to

I don't actually like this second ball. So just let's keep the first bolt on this one. But yeah.

Ryan Koch (51:41.903)
sorry, sorry, out out of interview character question. Sorry, you wanted me to cut that off at a certain place or?

David (51:44.638)
Sorry. Yeah, I kinda broke there. Yeah. Yeah, yeah, that second that second bullet I I I just shouldn't have gone on. So yeah, I I think that first bullet though was all right.

Ryan Koch (51:57.901)
Okay, cool, cool. I think maybe what I'll do just to make sure I get it right in editing is I'll have a big transcript at the end that I'll I'll maybe I'll just give it to guys. And if you give me a hint about like where you wanted to cut the answer off, I can

David (52:03.49)
Okay.

David (52:09.238)
Yeah. I I think that f the first sorry, sorry, I think the the one about like

Ryan Koch (52:12.309)
Or if you wanna make another go, that's also cool tool cool too. Either way. Yeah.

David (52:15.894)
yeah, the w yeah, just in the tri the one about the like monetization being like multiple layers. I think we can like run with that one and then what but yeah, that's fine. Sorry about that.

Ryan Koch (52:35.967)
yeah, that that's a fair point.

David (52:38.636)
Yeah. I also want to redo the intro if we if we can, if we've got time.

David (52:46.847)
do you do you want me just give the answer again or do you want to ask the question again?

Ryan Koch (52:52.675)
can I can I ask like an abbreviated actually hold on, how did I let me think about how I asked it again. I I did that as improv.

David (52:55.672)
Sure.

David (53:01.902)
Ha ha

Ryan Koch (53:05.087)
Okay. Alright, I think I alright, I think I can recreate it again. Okay.

Ryan Koch (53:11.371)
David, as we get to the the tail end of our conversation, you know, we've covered a fair bit of ground. We've talked about the lockpick concept and kind of how that becomes reasonable stuff between different efforts. We've talked about modernization strategies, the pros, the cons, the indifferent things between them. And we've even talked about where artificial intelligence can kind of fit in and around these kind this kind of work. If there's one or two things from what we've talked about today that folks would take into their day and beyond.

what would you hope those would be?

David (53:44.909)
Yeah, I think that's a that's a really that's a really great question. you know, I think the the one thing I would kind of like underscore as we get to the end here is around and it's been a it's been a theme that we've kind of talked about through this entire conversation, but is is the idea that like legacy modernization is is more than just a technology effort. like yes, yes, there's a technology component too, but when you think about modernizing government services,

You have to work across policy, you have to work across organizational challenges, you have to work across business processes. and so these efforts are really about thinking about how all those things kind of come together to rethink how services should be delivered. and so at the end of the day, like, you know, just reducing it to a technology problem, I think doesn't get to like the full essence or even like full challenge of what modernization means, especially in the government space.

Ryan Koch (54:43.838)
David, thank you again for coming on Civic Tech Chat and joining us for this conversation.

David (54:49.134)
Thanks so much, Ryan. I appreciated it.

Ryan Koch (54:53.492)
Cool and I'm leaving us a recording for a minute. You said you wanted to say your intro again? Did I hear that right?

David (54:58.336)
Yeah, can we just do the intro again? I got kinda I kinda trailed off. It could have been sharper.

Ryan Koch (55:03.506)
Yeah, yeah, I can do that. I can always then I'll I I'll ask the question again like we just did. all right.

David (55:08.547)
Thanks.

Ryan Koch (55:12.85)
David, thanks so much for joining us here on Civic Tech Chat. Could you introduce yourself and tell us a bit about what you do?

David (55:20.878)
Of course, I'm David Da Silva. I'm a principal product manager in technology solutions solutions. my goodness. No, I'm gonna let's do that one more time. Sorry.

David (55:34.258)
all right, I'll just I'll just go. I take it.

Ryan Koch (55:39.495)
actually I'll I'll ask again s 'cause it's it'll be more natural. Yeah, yeah. Okay. David, thank you so much for joining us here on Civic Tech Chat. Could you introduce yourself and tell us a bit about what you do?

David (55:41.59)
Yeah, yeah, yeah, okay. Yeah.

David (55:53.974)
Yeah, absolutely. I'm David Da Silva. I'm a principal product manager at Nava. for those who don't know, Nava is a public benefit corporation whose mission is to help government agencies make services more simple and effective. inside of Nava, I work in our technology solutions and services team with a particular focus around legacy modernization. So we think a lot about how to help teams sort of leverage our learnings from projects and you know.

Not have to so much reinvent the wheel every time that they start a legacy modernization.

Ryan Koch (56:30.13)
Cool. Okay. And I will hit a stop here.