You can use MDriven to keep the long-lived meaning of your business system in a model while evolving its user interface and delivery separately; this page is for teams planning software that must remain understandable and changeable over time.
The next step: separate meaning from delivery
When you build an information system, you solve two different problems:
- System gist is the enduring meaning of the system: the information the business needs, the relationships between that information, and the rules and processes that govern it.
- Modernity is how the system is delivered and experienced at a particular time: its user interface, presentation, and the technical approach used to run it.
Treat these as separate concerns. Put the system gist in the model, and use an execution engine and user interface appropriate for the current delivery need. This lets you invest in the business knowledge without making that knowledge depend on a particular presentation or technology choice.
For example, a vehicle-sales system may need to represent a car, its current owner, and an ownership transaction. These concepts and their relationships are part of the system gist. Whether users work with the system in a web-based interface or a rich client application is a delivery decision. The ownership information and the rule that a sale requires a buyer should remain part of the model as the delivery changes.
Keep the business knowledge in the model
A model is more than a diagram. In MDriven, you use the model to describe the information structure and the behavior that belongs to that structure. The model can become the documentation, shared know-how, and maintained description of what the system does.
Invest heavily in making this description accurate. Involve the people responsible for the business in decisions about the system gist, so they can review and govern the information and rules that the organization depends on.
Questions that belong to system-gist work include:
- What information must the organization keep?
- Which concepts are related?
- Which states and processes are valid?
- Which rules must always be true?
- Who may view or change information?
For example, the statement âa sale cannot be closed until it has a buyerâ is a business rule. It belongs with the modeled ownership process, rather than being defined only by a particular screen. See Training:Bootcamp:Chapter 9 for an example that models an ownership transaction, guards a transition by checking for a buyer, and verifies the result in the application.
Let delivery evolve independently
User-interface conventions and technical expectations change. Keep these modernity concerns distinct from the modeled business knowledge so that changing presentation does not require rediscovering or rewriting the system's meaning.
MDriven supports modeling, prototyping, and execution, and can take a model toward a system with a web-based user interface and/or a rich client application. This makes it possible to work on the model while choosing delivery mechanisms that fit the current need. For an overview, see Training:What is MDriven.
The separation does not mean that user experience is unimportant. You should invest in both areas, but make the boundary clear:
| Area | Primary concern | Example |
|---|---|---|
| System gist | Correct information, relationships, rules, and processes | A car has a current owner; an ownership transaction must have a buyer before it can close. |
| Modernity | How people use and receive the system | A view arranges fields, grids, actions, and diagrams for a web page. |
A ViewModel is an example of work on the delivery side: it shapes how modeled information and actions are presented to the user. You can refine layouts, visibility, and available actions without changing the underlying business concept. See Training:Bootcamp:Chapter 8 for practical ViewModel layout work and Training:Bootcamp:Chapter 5 for actions in a ViewModel.
Apply the separation when you design
Use the following sequence when starting or changing a system:
- Identify the business concepts, information, relationships, and rules that must remain valid over time.
- Describe those concerns in the model. Make the model understandable enough that business stakeholders can participate in decisions about it.
- Test the model by executing it and working with realistic examples.
- Create or adjust ViewModels and other delivery details for the users' current tasks.
- When presentation needs change, change the delivery layer while preserving the modeled information and rules unless the business meaning itself has changed.
For example, if administrators alone may change a car's brand, first identify this as an access rule. Then express the rule where it governs the relevant modeled information and verify it with users in different roles. The presentation can also hide or make the field read-only for non-administrators, but the rule must remain clear and maintainable. Training:Bootcamp:Chapter 12 walks through this distinction in a concrete ViewModel configuration.
Why this matters
When system gist and modernity are entangled, a change in delivery can become a risky rewrite of business knowledge. Teams may then spend their effort changing presentation and behavior together, even when only one of them needs to change.
Keeping the concerns separate gives the organization a maintained description of its own information and how it works. It also makes it easier to evolve the system in smaller, more focused changes. The model remains the place to understand the system; delivery mechanisms can evolve as requirements change.
This approach requires discipline. Do not let an argument about current interface fashion redefine a business concept without checking whether the underlying business meaning has actually changed. Likewise, do not treat a business rule as a screen-only behavior if it must hold wherever the information is used.
Prepare for information design
The next step is to make the system gist explicit by designing the information the business needs to manage. Start by naming the concepts that matter to the business, then determine their properties, relationships, and rules. Use concrete examples from the business to confirm that the model describes real work rather than only a preferred interface.