Here is Chapter 16, the final chapter of Mixed Model Arts, Book One. I think this is a great way to close out this book, and I hope you enjoy it.

Chapter 14 (the levels of data modeling) will be published next week. I’m doing artwork right now. Then I’m off to do copy editing, make a few final micro-tweaks in various chapters, and get the book formatted for publication. Stay tuned for more information, especially as I move into the book launch phase. Thanks for your support on this project, especially since it’s taken forever. It means a lot, and I think this book will help a lot of people on their journey to become better data practitioners. Joe You’ve made it to the final chapter. If you’ve read this far, you understand what you’re modeling: the processes and domains that drive the business. You can navigate the levels from conceptual to physical. You’ve confronted the organizational realities—the people, politics, and ownership questions that determine whether data modeling initiatives live or die. Now it’s time to talk about velocity. This chapter is about what comes next and how to keep your data models alive in a world moving faster than ever. Back at UFC 1, Art Jimmerson walked into the octagon wearing one boxing glove. Everyone brought one style and thought it was enough. Within a decade, single-style fighters were obsolete. Then specialists came back, but as specialists who understood the full landscape and chose where to focus. The sport still hasn’t arrived at a final form. It’s still evolving today, with ever more capable and dangerous fighters. Data modeling follows the same arc. Your first model is never your final model. Requirements shift, technology changes, and the business evolves. The practitioners who last are the ones who treat modeling as continuous practice—like training—not a one-time project. You don’t stop practicing because you had one bad round. You keep showing up. Let’s begin with a conversation that changed how I think about this work. The “Done” DelusionOn a podcast I recorded with my friends Remco Broekmans and Marco Wobben, Marco brought up a point that completely stopped me in my tracks. It’s one of those ideas that, once you hear it, seems obvious, yet it challenges a core assumption I (and I think many of us) hold about our work. Most of my experiences with data, ML, and AI initiatives are treated as finite projects to be “done.” Of course, we all know that many apps or data models aren’t one-offs; they evolve. But even then, we tend to handle that evolution in sprints, with a neat little dopamine hit of “done” at the end of each cycle. We build the thing, we ship it, we iterate, but the initiative itself has a beginning and an end. Is Data Modeling a Program or a Project?Marco’s world is different. Where he works in the Netherlands, data and information modeling is treated as continuous work in progress, without a specific notion of “done” or ending. He framed it perfectly: they don’t treat modeling as an initiative or a project. They treat it as a program. This isn’t just a semantic argument. In Marco’s case, his modeling activities have gone on for almost two decades and will likely continue indefinitely. That’s different from how many practitioners approach data modeling, which they treat as a project. But taking a step back, data modeling is more akin to a program. Data modeling isn’t a task you complete only once. It’s a core, perpetual business function, like finance or operations. It’s not one-and-done but a living, breathing activity. This simple reframing helped me see data modeling not as a one-time setup, but as a continual activity of making sense of the evolving reality in an organization. Continuous Sense-MakingWe all intuitively know this, but it’s easy to forget in the day-to-day grind. The data model is a living reflection of the business, and as the business evolves, the model must evolve with it—not in fits and starts, but fluidly and continuously. Despite the best intentions, modeling is usually seen as something you do at the start of a new project or revisit annually. Or, if we’re being painfully honest, it’s something we only fix when it breaks. And especially in organizations with tight time constraints, data modeling is often seen as a nice-to-have if it’s done intentionally at all. Often, data modeling takes the form of throwing data into a pile and calling it a day. The Ownership ProblemThere’s a deeper issue beneath the surface: data is like water. It flows everywhere, and in many organizations, it’s owned by nobody. When ownership is diffuse, accountability becomes impossible. If everyone is responsible for data quality, no one is. This is why treating data modeling as a program—with dedicated stewards, continuous investment, and clear governance—matters so much. Someone needs to be the custodian of the map, ensuring it stays aligned with the territory. In many organizations, there is no dedicated data modeler title. Instead, data modeling is a skill practiced by data engineers, analytics engineers, backend engineers, and data architects. This is both a challenge and an opportunity. The challenge: Modeling is treated as an afterthought when no one explicitly owns it. The opportunity: modeling literacy across the team means models are informed by diverse perspectives. The Mixed Model Artist philosophy holds that everyone who touches data should understand the fundamentals of modeling. The depth varies. A data engineer needs deep modeling skills, while a data scientist needs enough to design good feature stores and understand the data they consume. But someone, somewhere, must own the program.

          Read more
       (https://practicaldatamodeling.substack.com/p/ch-16-be-water-the-continuous-practice)