Modeling the mission: why Domain-Driven Design matters for government software

When a government software program goes sideways, the post-mortem usually blames the technology, the contract, or the team. The real culprit sits upstream of all three: a domain nobody understood before writing code.

Domain-driven design starts somewhere different. Understand the work first. Build the software around a model of the work. And keep deepening that understanding as the code and the shared language evolve together. The modeling doesn't stop when development starts.

In this Mission O/S Live, Rise8's VP of Enablement Adam Furtado sits down with Rise8 Founder & CEO Bryon Kroger and Paul Rayner—longtime DDD practitioner and author of The EventStorming Handbook—to talk about what it takes to model a mission well, and why so many government programs skip the step entirely.

They'll cover:

• Why software built around the org chart breaks down, and what shifts when teams model the domain instead
• How event storming surfaces hidden complexity early, before it turns into a delivery crisis
• The quiet cost of teams, leaders, and stakeholders all using different words for the same thing, and how shared language changes delivery
• Why bounded contexts matter more than ever as AI accelerates how fast teams ship software
• Where to start with DDD on a program that's already mid-flight

You'll leave with a sharper way to diagnose what's going wrong on a struggling program, and a starting place to fix it. If you've ever watched a team ship the wrong thing on time and on budget, this one's for you.

Adam Furtado (00:30):

All right. Welcome everybody to Mission OS Live. I'm your host, Adam Furtado. And for those of you who are with us for the first time, Mission OS is Rise8's framework for how gov tech organizations actually ship software that matters, not just on time and on budget, but to production delivering real outcomes to real users. Our CEO, Bryon Kroeger, who also joining us today, has released a 16 episode masterclass series, breaking all of that down from procurement to culture, cloud to strategy. It's all in there. And these live streams are where we extend that conversation with the people who are pushing the edge of what's possible in GovTech. So each episode, we're going to bring in somebody with deep industry expertise and pair that with somebody with deep government expertise because that combination, that seam is exactly what these problems require. So today's a great example of that.

(01:23)
Paul Rayner, the founder of Virtual Genius, a longtime domain driven design practitioner and the author of the Event Storming Handbook is joining us today. He spent over 35 years helping organizations from startups to Fortune 500s tackle complex software problems through one pretty radical idea that the best software doesn't come from top down mandates or pre-specified requirements. It emerges when business stakeholders, developers, domain experts model the work together before anyone writes code. We had Paul speak at ShipSummit earlier this year. He did a talk called Design in the Loop, and it's one that's really stuck with a lot of us at RiseData ever since myself included. So Paul, welcome. I'm glad you joined us.

Paul Rayner (02:04):

Yeah, thanks, Adam. Thanks, Bryon. Great to be here.

Adam Furtado (02:07):

Cool. And then joining us today to tackle the gov tech perspective and how this is applied to the world that we all live in. Bryon Kroger, RiseAid's founder and CEO, and someone who has spent a long time inside government trying to make this exact work come to fruition in practice. So Bryon, good to have you as always.

Bryon Kroger (02:25):

Hey, great to be here.

Adam Furtado (02:27):

Cool. Here's where I want to start. There's a line in how we promoted today's episode that I haven't really been able to shake. So good job to our marketing team. They said if you've ever watched a team ship the wrong thing on time and on budget, then this one's for you. And I thought it was an interesting framing here and there's a pattern that those of us who live and breathe this space here have seen over and over again. And that's sort of what we're going to talk about, what sits upstream of all of the work that we've talked about in other episodes. So I'm excited to jump in. Paul, we're going to start with you and I want to start with the failure mode here, not like the AI version, which we'll get into later in the episode, just the classic version. When a software program goes sideways, the postmortem usually blames the contract, the vendor, the team.

(03:18)
You'd argue the real problem sits upstream of all of that. What's actually breaking?

Paul Rayner (03:25):

What's breaking? It does, I believe, sit upstream and so much of it has to do with actually understanding the problems that you're trying to solve and getting the people involved in delivering the solution to have an understanding of the problem, what we would say in domain-driven design and understanding of the domain, the actual business domain, the space that you're working in before you actually move forward with trying to commit to a solution for that. What happens on so many projects is that the biggest decisions are made with the least amount of information at the beginning and those decisions get locked in and calcify for everyone as the project moves forward. Whereas the idea with domain-driven design is let's collaboratively bring in the diverse perspectives of the people that are the practitioners, the experts in this area of the domain and start with a model that develops a shared understanding and a shared language about what it is that we're actually trying to accomplish.

(04:26)
What are the goals? What's the problem? And being able to move forward from there. So that's the starting point that then enriches everything downstream from there. And the failure mode that you're describing is where that doesn't happen, where you jump straight to a solution without really understanding the problem.

Adam Furtado (04:42):

Yeah. I find these concepts super fascinating in that we're applying very human concepts to very technical problems. I think sometimes we forget the order of events in these cases. And Bryon, I think the government application here is even more challenging. There's kind of a structural version of this problem that I think is worth naming. It isn't entirely unique to government, but certainly exacerbated here. The leaders of programs, the leaders of procurements largely aren't experts in the domains of their programs in many cases. A PM or a material leader for a large software program is just as likely to have been procuring tanks or manila envelopes in their last job. How does the domain context gap show itself within the government knowing the kind of framework that we live within and how should we think about combating that?

Bryon Kroger (05:33):

Yeah. Maybe one thing I'll highlight before I get into that too is Paul mentioned jumping straight to the answer. I would say there's even more pressure in government a lot of times because you have these five, 10-year programs that are on their third run. So it's been 30 years and the software still hasn't been replaced. And so the level of urgency and oversight, you've literally got Congress calling you on the floor to testify. It actually creates a doom loop. It makes it even worse. But to your point, there's this interesting thing that a lot of business domains, even if you're not intimately familiar with them, are fairly intuitive, but understanding how a targeting process works is just like if we were building a shopping app, we all generally understand how shopping works. So even if you're not an expert in e-commerce, you can kind of get by.

(06:22)
You just can't do that in this space. And then you have three overlapping domains and value streams. There's the actual mission, that's what we'll be talking about here, targeting. And that's supported by an IT delivery stream. Now, every commercial business has this to force ... Well, at least maybe the good ones don't have this, but this gap between IT and the business. And so that's even more pronounced in government. And then there's the procurement value stream to get the IT services to get the mission done. And all three of those value streams are relatively broken. And so it makes it really difficult. They might come in with no software domain expertise, no mission domain expertise, and maybe even not a lot of functional procurement expertise. So it's a real challenge.

Adam Furtado (07:12):

Yeah, but they still have to write a contract. They're still going to put it out so we can kind of see how that plays out. In a situation like this, Paul, one of the techniques that you espouse and you've been kind of an expert in bringing to the field is a technique called event storming. And EventStorming something that's also in the masterclass, Bryon referenced its application in government as well in episode 10. For someone who's never seen it, not a developer necessarily, a thing of program manager, government leader, somebody who's in the business side, if you will, what actually happens in that room? Why is that such a good technique for solving some of the problems we're talking about?

Paul Rayner (07:49):

Yeah. So quick summary of event storming is imagine going to a very hands-on collaborative workshop where the key players in say a value stream and the area that you're working in are put in a room and what they do is they map out the business process using sticky notes on a wall. And it's actually optimized for that collaborative participatory approach so that all that tacit knowledge that is buried in people's minds from either years of working in a space or expertise about the existing systems in a space, because there are always existing processes and existing systems that you have to work with all of that gets mapped on the wall as sticky notes. You're basically telling the story of a business process using sticky notes where each sticky note represents something that happened in that process. So for somebody that's never experienced that, think about the way that a company like Pixar might storyboard out a movie before they actually animate the movie.

(08:57)
It's a little bit like that storyboarding process, but using sticky notes. So it's very accessible and fast and you can get up to speed with a business process in hours instead of the usual weeks that it would take to do that. And not only that, because everyone's in the room, there's a sense of team building and diverse perspectives that are being reconciled as part of that process. So that shared understanding is organically developing as part of the actual technique and you're surfacing with event storming not only the story, but what systems are involved, who are the people involved, what are the key events in that process? What are the handoffs from one area to another? So there's a lot of richness that gets layered into this timeline, this visualization that then can carry forward into not only understanding what the problem is, but then figuring out the best solutions for that as the team moves forward.

Adam Furtado (09:58):

There's probably a lot of power in taking engineers away from the keyboard for a minute to think about the business and the thing they're actually trying to solve the outcomes we're trying to produce and think about in that context. Paul, we had talked a couple of weeks ago and you told this great story about event storming that you facilitated with the group and there was the burnt toast story. Would you mind sharing that anecdote?

Paul Rayner (10:23):

So a situation where a company mapped out a very large data and complicated data ingestion pipeline that they wanted to improve and there were numerous legacy systems that were doing too much sitting in that pipeline, or at least that's the sense that everyone had. So we gathered about 20 people in this large workshop and flew some in from different parts of the organization and mapped out that entire process end to end on about 30 feet of wall space over the course of just over a day. And one of the comments that stood out to me was about two thirds of the way down the wall, there was somebody that owned that part of the process saying, "I have a whole group of people in Manila that are fixing data problems that I now see are being caused about 15 feet up the wall from me.”

(11:17)
And if we were able to tighten up the validation and verification upstream from me, then I wouldn't need so much of this corrective activity. And the way he framed it is it's like we're burning the toast up near the front and then I'm spending a million dollars a year scraping the burnt toast down in this part of the process. And so that holistic view is so critical and that doesn't necessarily mean that they needed a software fix for that. That was more recognizing that these processes grow organically and the software we develop for them often grows organically. And without a holistic picture, it's very difficult to know where to invest the effort, where strategically it makes the most sense to invest in custom software development. And you could be solving the wrong problem, you could be just scraping toast and not even knowing that you're doing it.

Adam Furtado (12:12):

I'm curious, Paul, in that example, did those teams know each other? Was there already a relationship or like what were they uncovering for the first time? Just in that moment, do you remember?

Paul Rayner (12:22):

Yeah, that's a great question. So we had a very diverse group. So we had people from this entire value stream that worked all the way from sourcing the data all the way to presenting the data to the customers. So there were multiple people in the room that didn't normally work together and they had awareness of their part of the process, but not how that fitted into the whole. Nobody had a holistic view of what was going on in the entire process. So it's a similar kind of feeling to value stream mapping in that sense, but what eventstorming brings to the table is we are able to surface what software systems underlie this and where are the handoffs between different groups happening. Often what I find is a lot of the problems that happen occur around these handoffs, right where one siloed part of the organization has some kind of API that they're calling for another part of the organization, but there's not a lot of conversation about the shape of the API, what validation do we need?

(13:30)
Each part of the organization is optimizing for their own part of the flow instead of thinking about the overall flow. So very diverse group and that's part of the power of the technique no matter what flight level you're at.

Adam Furtado (13:42):

Right. Makes sense. Bryon, can you think of an example that sound like from the government context that you've seen similar things?

Bryon Kroger (13:51):

Yeah. I mean, I can tell you one of my greatest regrets and where this went poorly and then maybe a positive example way back when we were starting Kestle Run, I remember doing an event storming of what was called the Theater Battle Management Core System, TBMCS, huge legacy system. And one of the goals from our stakeholders was to deprecate this entire legacy system, which probably shouldn't have been the goal. The goal was some sort of functional improvement. And I say that because I noted when we did the event storming that there were so many bounded contexts and ubiquitous language translation between all of these contexts, it was a lot to unpack. And because we didn't have those properly identified, I would say, one, I mean, big bang replacements are always going to fail, but even as we tried to develop around the seams of that legacy system, we didn't have a good understanding of feasibility.

(14:54)
So everything was being driven by user pain and more of the value stream business side and not the underlying technical feasibility of where we can start breaking apart these seams and integrating our own context. And so I think Kesselrun in my view, it's my baby, but it was doomed to fail by our unwillingness. I did try to fight the fight for what it's worth. I said that we should try to break apart that TBMCS system and work within those seams, but we just weren't allowed to. And I wish I would've died on that hill. But knowing that one of my first projects with Rise8 was Kobyashimuru, Space Force Project Section 31, and we were building for the space tasking cycle, so a very similar mission and we convinced them to do this process upfront and really identify where we needed to work first. And so it ended up being almost the exact opposite of what users and folks on the ground thought we should do from a functional perspective.

(15:56)
And they were right, the most functional value is where they were pointing, but unlocking that value required doing a whole lot of architecture, re-architecting of the system to be able to enable those functions or we would break a bunch of downstream functions. And so I think it's super important if you can do that before you even go on contract because one thing I'll just add there is the bounded context if you're in government, you should hear that and think dependency management because usually a bounded context get assigned to each vendor. It's just the way government breaks apart work for fair contracting, et cetera. And if you start the wrong things in the wrong order, you create a dependency management nightmare between vendors.

Adam Furtado (16:38):

Yeah, it's great. I actually want to go there. I think we can dive a little bit deeper into that last part about if you're a government person watching this as an example, like how might I apply these things in reality in a large scale system? In your masterclass in episode 10, there was sort of a three-step approach to this when you talked about domain-driven design. The first step was this event storming process we're talking through. The second was identifying bounded context, as we just sort of went through a couple of examples of that. And the third was defining your future architecture. Now I've been working in and around government my whole career and I would tell you almost every procurement starts with number three and generally those things are getting defined upfront so that way when it goes on contract, the government is de- risking things and for largely good reasons, I think we want to get as much into that contract as possible.

(17:29)
Can you talk a little, what should the government do differently here? What can they do within contracts to buy down that risk in the same way, but still leave the door open to make better decisions? But what does that look like in practice?

Bryon Kroger (17:44):

So we do value stream and event storming workshops as much as I love doing those post-contract, I really wish they would maybe hire people like Paul or somebody else to come in before they even even think about a contract and set us on what we should be working on and they've already figured all of this out. It's actually very painful to figure out after the fact we end up having to restaff completely different tech stacks than we thought we were going to be working with. It can be a real difficult thing on the vendor side and then the government doesn't get the outcomes they're looking for. So I would actually love for them to find experts like Paul and do that work upfront and use that to determine what the contract should look like.

Adam Furtado (18:29):

Right. Right, thanks. The last component of domain-driven design is ubiquitous language. And we kind of talked about this briefly earlier and I think it's been described before as the quiet cost of teams, leaders and stakeholders all using different words for the same You've called this a ubiquitous language problem. Why does this matter so much and what does it cost when nobody fixes it at the root?

Paul Rayner (19:00):

So every challenge I think we face in software ultimately comes back to some kind of disconnect in terms of communication. And so the focus in domain-driven design on language is foundational to the entire enterprise because when on person uses a particular term and it's understood five different ways by other people in the room, you are setting yourself up for failure in terms of what makes it into the software is going to be that confusion and that diffusion. And so domain-driven design says we need to pay a lot of attention to the context that we're working in. So what Bryon described as the bounded context and then within each context, what is the language that we're using and then paying very careful attention to where we have to translate from one context to another. That could be as simple as integrating with a system that works in metric units and you're working in Fahrenheit, for example, and not being aware that degrees means something different in the system you're integrating with.

(20:23)
It could be something as trivial as that, but multiply that by a thousand decisions being made on a project and becomes very, very important to be able to say, in this context, here's what this concept means, here's examples of it and here are the business rules that we want to keep consistent in this context and here are the boundaries where we need to be translating to other concepts. If you can't do that, then you're going to inevitably have software that is going to not handle that translation well and have put the burden on the users to do that instead.

Adam Furtado (21:01):

Yeah. Just the amount of cognitive burden in every interaction just grows. Absolutely. I guess Bryon, from a government perspective, now you've got policy people and acquisition folks, operators, developers, vendors, all within the same program, all coming with their own language in a lot of cases. Where have you seen that kind of a vocabulary gap show up?

Bryon Kroger (21:24):

I mean, I've seen some major ones like even it's not even between the programs in the mission side of the house where folks use the word target differently across the services and then even within each military service, like within different directorates a lot of times. So like Target Strike was another one that we found actually when we implemented the first version of a tool called Mirader, Marader does misrep analysis for any mission report, but the main one that people were pulling at the time because we were in an active conflict was ones for strikes and the language that we were using, we were swapping out a legacy system and they had built in a export import feature for CSV and they were doing a language translation at that layer. We didn't know that was happening. We changed the language and we broke all of those somewhat manual integrations that a downstream function had, which was doing the battle damage assessment for the entire air campaign.

(22:25)
So it's like kind of a big deal. And then it gets even worse when you start pulling in people who don't have that mission domain expertise and there's these common use words that you just think, oh, that's ridiculous, but they can break things really quickly.

Adam Furtado (22:38):

Yeah. I've seen this be harder and harder the last few years for a bunch of reasons. One, the shift to remote work moved everything to be more async. I don't know how many times we've seen sending something in Slack that means one thing to you could be perceived in a different way to somebody else. Or even with as much AI as we're using, we're communicating more in kind of text-based asynchronous formats, less visual. So all of those gaps in information people are filling in those gaps with their own mental models and all of a sudden you have this divergence that you may not have expected. So I think this is becoming even more challenging. And then to continue that thread, I guess, into, okay, what's changed now with AI in the last year, 18 months in this domain-driven design space? Paul, in your shift summit talk, that really was great, by the way.

(23:29)
So thank you for joining us there in Utah. Again, it's called Design in the Loop. The thesis essentially was when AI generates most of the code, the work that matters changes. So can you say that plainly? What changes? Why does it make domain modeling that much more important and not less?

Paul Rayner (23:52):

It makes it more important because we're seeing a shift in the industry towards people moving towards documenting specifications in markdown files and throwing those at an AI and a lot of expectations that you can just one shot a solution based on that. And there are a set of cases where that could work in a well understood domain, but the vast majority of what we're building in software, the features we're building, the capabilities we're building are very complex and require doing discovery work. You don't know the solution ahead of time and the kind of design and discovery work that you need to do becomes even more critical. The visual work that you need to do becomes even more critical. And so techniques like event storming, getting everyone on the same page, creating mock-ups of UIs, prototypes, proof of concepts, I think becomes more critical now because the generation of the code is not the bit that slows us down so much anymore.

(25:02)
And then related to that is the verification after you've built something. So practices like test driven development, doing discovery work not only at the start of a project, but as you proceed is going to become more and more critical I think for teams, keeping everyone on the same page. I've said in my talk at ShipSummit that a little bit of mist in your mind is going to be an impenetrable fog by the time it reaches the AI. And I think that bears out not just for individual developers, but in teams as well.

Adam Furtado (25:36):

Yeah. It's a cool kind of connection between the last two conversations we just had is that the challenge with not having even ubiquitous language or this kind of common vernacular way of thinking about things certainly gets exacerbated in a world where AI is trying to understand what you're thinking and we always struggle with that communication. Bryon, this is something I think we talk about a lot at work and have a normal day-to-day, this idea of AI obviously allows us to build things more quickly, but how do we make sure that we're building the right things, not just building the wrong things more quickly? How do you think that's playing out in government or will play out, I guess, as we adapt to this kind of new world?

Bryon Kroger (26:29):

I'm a little bit afraid in the sense that at RISE-8, we've developed these ways of working with our balanced team model of product management, design, engineering, the way that we approach extreme programming and our engineering discipline is a well-architected flow. And so dual track development, for instance, where we have design working on things in certain ratios on certain time horizons for engineering. So they're constantly researching the next feature, designing the current iteration or sorry, the next iteration feature and then testing the last iteration feature with users. Well, if you're generating code 10 times faster, they have to do all that 10 times faster, but you can't actually do all those things 10 times faster without you implementing AI yourself. And so for us, that's as simple as saying like, "Oh, this is a flow problem. We've increased flow 10X over here. We just need to ... " It's not that these are more important, it's just that we've created a bottleneck over here actually on both sides, upfront work and as Paul highlighted on the backend of the validation.

(27:38)
I feel confident that we can solve that at Rise eight. The problem is both of those things that I just mentioned are historically already neglected in the government. In fact, a lot of government with maybe a few pockets of exceptions don't even talk about user centered design or implemented into the development process. Design might be, if you're lucky, a phase that happens before the project starts and then product management isn't a thing either. There's just projects, there's no product. And then don't even get me started on testing and cybersecurity. So I feel like those were already the bottlenecks or even maybe non-existent functions in government and now they're about to get 10 to maybe in the future 100x demand placed on them and you're just going to get even worse outcomes than we are already seeing. So it's like get government to invest in those things and then really double down on making them AI native.

(28:32)
Maybe we can jump straight to AI native and we'll save the day, but it's tough.

Adam Furtado (28:37):

Yeah. To tie a couple of those things together, Paul, we've talked a little bit about how domain-driven design and some of these concepts and tactics can actually help as you use AI. There's a research named Anagrit Yunker that you've referenced before in an experiment she ran in this sort of area. Would you mind telling the audience about that?

Paul Rayner (29:02):

Sure. She's been doing some really exciting work in this space. So she was comparing asking an AI to solve a particular problem with just the regular context that you might provide in a specification and seeing the results that came from that and then comparing that, for example, to injecting a photograph of an event storming timeline into the context, giving it the same prompt and then running it again in a fresh context and seeing vastly improved results from injecting in the event storming timeline to just the bare prompts. And I've seen the same types of things in my work as well is that LLMs, agents are really good at consuming this type of information and providing or being able to take visual information to take Like the type of condensed knowledge that exists in say an event storming timeline or some kind of domain model that the team has developed and then being able to use that as the broader context for what the LLM needs to build instead of this very kind of not being able to see the forest for the trees kind of approach of we're just going to work on this one feature in isolation of the larger context.

(30:27)
And so one of the things that I think we're seeing is that what's good for us as humans is also good for the agents in terms of fleshing out that context, using visuals, taking the output of collaborative learning and that shared understanding and that shared language and providing that to these agents as a richer context for them to provide the types of outputs that we're actually looking for to get the outcomes that we're actually looking for.

Adam Furtado (30:54):

Can we stay there a bit? We had a number of pre-submitted questions and two of them I think are relevant to where you're headed here. The first one says, how does an org maintain or manage to retain respective domain knowledge with PMs and engineers moving to other roles after three to five years? How do we maintain that kind of organizational knowledge? And then related to it, I think if decision velocity is the goal, how important is it for teams to have a trusted way to access internal knowledge across docs, people, workflows before they're laying on AI initiatives? And the way I think about this is you talked about event storming, we're going to put sticky notes up on a wall in person hopefully and with people and all of that. But now we're talking about the implementation of AI and being able to understand context of an organization and implement.

(31:40)
How do we bridge those two things, this kind of analog craft if you will, but then like the technological nature of the work that we're doing today?

Paul Rayner (31:49):

I have a couple of thoughts on that. Number one is that for a lot of existing systems, we can use AI to work with the people that are most knowledgeable about the system to generate documents and diagrams that explain how the system works, not by just one shotting that with the AI, because it's going to get it wrong, but using that knowledge that somebody has before they transition off a system to actually capture that knowledge within the code base itself that describes the intent using automated tests as a way of having an executable specification for the system that endures and carries on to the next generation of engineers and product managers. I think part of the story is leaning on AI to help with generating artifacts, not in a naive way, but taking the knowledge that's already in people's minds and including that in the actual system itself.

(32:48)
And then I think the other side of it is taking the artifacts that have been generated and incorporating those in as well I think is part of that whole process because we need more than just cave drawings, right? You walk in and you just kind of see some cave drawings and you have to figure out what went on. What we're often missing is why were these decisions made? So things like architecture decision records, for example, and capturing that knowledge, like I said, and incorporating that into the system so that the LLMs in future can make the right choices along with the humans as well.

Adam Furtado (33:29):

Bryon, I know you have thoughts here. This is one of those things that we talk about a lot internally, maybe less so publicly or whatever, but the idea of just trying to capture as much data as we can so we can visualize our systems and that sort of thing. Do you want to share any of your thoughts around how you've been thinking about that the last six months or so?

Bryon Kroger (33:47):

Yeah. The limiting factor is the context window that can fit in your head. Dan North used to have a talk about this, I forget what it was, but essentially he said the limit of your code base should be, or like how do you define a microservice? How small do you go? Whatever. He said, it's the amount of context that can fit in the team's head. And I think similarly, when you zoom out to an organization level, we've always been limited by essentially the amount of context we can hold and process at one time and now that has drastically changed. So I feel like I'm sitting the stage for historically we would say, don't measure everything. That's a waste of time, energy, resources. It can actually lead to poor decisions or leaders looking at things that are too tactical and getting micromanaging with the teams. But I think in this new world, we should reassess that and some of those biases we have against measuring everything and capturing as much data as possible.

(34:46)
I would just say that most organizations should try to go all in. The problem though becomes defining canon and there's a lot of people that have thought for a long time, including the historic churches, like this is a long held problem for how you define canon. Star Wars has this problem too. And so I think you almost need a dedicated role in your organization to focus on what is canon versus some random thing somebody wrote. And then I would add on this topic of context, you mentioned the turnover in the question. Somebody asks government turnover is often like every three to five years. You should be revisiting these things on a regular cadence. We kind of recommend absent any major changes that are happening, you should just do it every quarter as a good practice. But I know Paul says anytime you're making a change, you should revisit event storming.

Paul Rayner (35:43):

A major change at least. Major change. Introducing new functionality, new capabilities, extending existing capabilities. There's a good chance that the people that are working on that we're not involved in writing the software for those capabilities. So there needs to be some knowledge transfer, otherwise your design is just going to become more and more fragmented over time.

Bryon Kroger (36:03):

Yeah. Paul, are you doing anything with ... This is super tactical, but Adam's thing of the diagrams on the board versus the diagrams and then getting them into an LLM. Are you doing anything with Mermaid or D2 as native diagramming languages or how are you handling that?

Paul Rayner (36:22):

So on any given day, I'm probably, if I'm writing some kind of specification for the LLM working on a plan, I'm including mermaid diagrams in that. I open sourced a tool called ContextFlow that allows teams to do context mapping over collaborative context mapping over an existing system. So being able to build up a context map and then make strategic decisions based on that. So I'm very actually excited about the possibilities that AI opens up in terms of building tooling to help us, not just with building features, but actually building tools to help us build features because that becomes a lot faster as well. So being able to take a tool like ContextFlow and open source it and then have other people contribute to that and then use that as a way of capturing this type of information I think is tremendously powerful.

Adam Furtado (37:23):

Cool. The show description, I think as we put this out, really promised people a starting place. So if somebody's watching this right now, Paul, they're mid-flight on a government program, they're realizing now maybe nobody did the upfront work that we talked about and they're kind of in the position that we were describing, what's the thing they do first? What do they go take from this and go try to start?

Paul Rayner (37:51):

So I think just a little bit of a nuanced answer is where are they feeling the pain? So if there's a profound lack of understanding, like Bryon had mentioned in a couple of examples of what are we doing and why that strategic kind of aspect, then something like a big picture eventstorming could be a way of aligning people and that typically points to some kind of discovery gap, discovery that didn't happen that is now manifesting itself in ways that makes it very hard for the team to actually provide the impact and the outcome. So if it's that kind of situation, then I think doing some discovery even at a small scale can really make a huge difference to the team. And then beyond that, I think there's a lot of techniques at the code level that can help as well in terms of the team doing some approach like eventstorming or context mapping or even just building a glossary of domain terms for their context can actually be a very high impact, low effort kind of accomplishment for a team to avoid the kinds of things that we were talking about in terms of translation errors and that type of thing.

Adam Furtado (39:09):

Cool, great. And then Bryon, same question to you. We're about to go into a three-day Memorial Day weekend. People are going to be spending some time outside barbecues also kind of reflecting on why we all do this work in the first place. We come back to work on Tuesday, we're motivated, we want to fix our program, make things better. What's the one thing that we do on Tuesday when we come back to the office?

Bryon Kroger (39:37):

I think maybe I'd be remiss if I didn't talk about outcomes. So taking what Paul said a step further is once you identify all of those bounded contexts and you understand where the pain is, but also where the friction is in the architecture, you start to see how you should prioritize your constraints in the system and those should be stated as outcomes that you want to achieve to alleviate the constraint or the technical friction. And those are the things that should go on contract. And what I'll tell you is a lot of government programs get wrapped up in like, "Oh, we've already executed these contracts." For the gov tech people out there, your program is congressionally mandated, but the contract itself is not ... You can cancel contracts, you can modify contracts, you can start over. And I would tell you, if you haven't done what we're talking about today already, it's not going to go well.

(40:36)
And so as painful as it is, it's worth stopping doing the event storming work that Paul has talked about and has a whole body of work out there if you want to go learn more about it and use that to define the outcomes that you should start working on starting on Tuesday.

Adam Furtado (40:53):

Great. Thanks, Bryon. This is a great conversation. Paul, thank you for joining us. This is the conversation that this show exists for. Is there anything you want to plug to the audience?

Paul Rayner (41:03):

Well, you already mentioned the event storming handbook, so that's available online as an ebook for people to download instantly. And then the other thing is that come September, the week of the 21st of September, we're running the Explore Domain Driven conference, explore domain driven design conference here in Denver, Colorado, where we have a whole bunch of hands-on content around things like exactly the kinds of things we've described today in terms of event storming and domain modeling. Anagrett, who we mentioned earlier, will actually be one of the speakers and will be giving a talk and a hands-on session. And so that's a great opportunity for people to dig in.

Adam Furtado (41:43):

Cool. We're sending a bunch of risers out there for the conference to upskill ourselves in this space, so we're looking forward to it. And then anybody else out there wants to go deeper on DD or VSMs, outcome-based contracting, vibe coding and government, reach out. We have a variety of workshops and labs that we'd love to chat with you about. And then don't forget this year's Predacity, August 25th to 27th in Nashville, Tennessee. I can promise you it'll be the best GovTech event of the year for folks who are really ready to make real change within their organizations. You might even see Paul there. We'll see. But Bryon, thanks for joining us as always and for everybody watching. We'll see you next time. Thanks for joining us. Go shift some outcomes.

‍