Model-Based Application Modernization: Have We Been Missing a Step?
A colleague of mine has spent over forty years advocating a simple yet underutilized idea: before we write code, we should define a clear, semantic model of the system we’re about to build. This notion isn’t new. In fact, it’s common practice in other disciplines. Architects create blueprints before construction, and mechanical engineers model components before manufacturing. Yet in software, teams often jump straight into design and coding after cobbling together requirements lists or interface mockups.
Why the disconnect? Part of the reason may be historical and cultural. While modeling languages like UML are taught in universities (I’ve done it) - where students learn the value of use cases, class diagrams, and sequence charts - these techniques often fall out of favor once real-world development begins. Many existing modeling tools, once heralded as breakthroughs, focus heavily on implementation details rather than capturing the more abstract, semantic understanding of a domain. As a result, the practice of semantic modeling, which should precede design and coding, is overshadowed by tools and approaches that help you move quickly toward code but not necessarily toward clarity.
Why go through the effort? Because it leads to projects delivered on time, within budget, and with fewer surprises. Teams spend less time on rework and more time ensuring the right requirements and correct design upfront. The result: less code, less complexity, and a smoother development process overall.
Try it—you might just wonder why you didn’t start sooner.
Semantic modeling vs Design modeling
I’ve often found this distinction tricky, likely because I started in software engineering. Semantic modeling aims to capture and communicate the policies and processes that define the problem, while design modeling focuses on describing a specific solution. Design modeling addresses the efficient use of resources, development costs, and maintenance. In contrast, semantic modeling manages complexity, isolates areas of expertise, and ensures agreement on the problem before building a solution.
The semantic model defines the problem in the language of domain experts, while the design model describes one of many solutions in the language of technical experts. They differ in goals, audience, and focus, but the overlap in their tools and language often causes confusion.
Agile methods
Agile methodologies have also influenced this trend. Agile’s emphasis on working software, iterative delivery, and responsiveness to change has rightfully improved many development processes. However, it can inadvertently discourage upfront modeling. Some teams perceive modeling as an “all-or-nothing” effort—either you specify the entire system upfront (and risk overengineering) or you dive in and adapt as you go. This leaves modeling stuck with a reputation as a heavyweight, academic exercise, when it doesn’t need to be. Even partial, evolving semantic models can help teams discover clearer domain boundaries, identify key concepts, and avoid misunderstanding the fundamental nature of what they’re building.
Contrary to popular belief, modeling doesn’t have to derail agility. It can complement it. Consider it a means to communicate domain knowledge: a map that shows what the system fundamentally does, who interacts with it, what data it manages, and how that data changes over time. This domain-level understanding can be established and refined incrementally, just like code.
From an organizational perspective, a semantic model can empower business analysts and domain experts to articulate requirements more effectively, using richer conceptual building blocks rather than just a list of features or wireframes. By focusing on “what” the system does rather than “how” it is implemented, the model can remain technology-agnostic and approachable. Later, as engineers engage, they can decide how to translate this conceptual map into an architecture and code. In other words, modeling doesn’t have to collapse the boundary between analysis and design—it can strengthen the analysis side, ensuring it provides more meaningful input to the technical team.
Application modernization
For modernization efforts, the value of modeling is even clearer. Legacy systems often embody decades of incremental changes, ad hoc decisions, and undocumented logic. Without a semantic model, you risk misunderstanding the system’s true structure and purpose. By first constructing a conceptual blueprint—potentially supported by AI-driven tools that help infer models from code and existing documentation—you gain a solid foundation. This can guide a more strategic rewrite, enabling you to treat the old codebase not as an inscrutable artifact but as a resource for discovering the system’s intended behavior.
With a sufficiently rich semantic model in place, the process of implementing or modernizing a system starts to resemble a compilation step. Just as a high-level programming language shields developers from low-level details, a well-defined domain model shields the development team from unnecessary complexity. Instead of painstakingly rewriting legacy functionality line by line, AI-assisted tools can leverage the semantic model to propose new code structures or even generate portions of the implementation automatically. This shifts the conversation from “How do we rebuild this system from scratch?” to “How can we refine and compile our conceptual understanding into working software?” It’s a subtle but powerful change, one that promises greater consistency, fewer misunderstandings, and faster adaptation to new technologies or platforms.
Leverage LLMs
Tools leveraging Large Language Models (LLMs) lower the barriers to creating and maintaining semantic models. By inferring models from documentation, code, or stakeholder conversations, they shift the focus from “How do we start?” to “How do we refine and improve?” This makes modeling more accessible and aligns it with agile, iterative practices, enhancing both code and conceptual understanding.
That’s the vision behind Monty: helping teams embrace a model-centric approach without feeling overwhelmed. We’re looking for organizations interested in piloting this approach—teams that value clearer domains and want to explore how modeling can integrate smoothly into their development process. Whether modernizing legacy systems or starting fresh, Monty supports the journey from concept to implementation.
If this resonates, let’s connect. Even small steps toward semantic modeling can deliver significant gains in quality, maintainability, and adaptability.