You can use this chapter to separate the enduring business meaning of a system from the technologies and presentation choices that change around it; it is for information architects, developers, and business stakeholders planning systems with a long lifespan.
The problem: different kinds of change become entangled
Software changes for different reasons and at different speeds. A business changes its rules, information, and working methods over time. Technology changes as platforms, user-interface approaches, security expectations, and deployment practices change. Visual preferences also change as users and markets prefer a different look or interaction style.
When all three kinds of change are expressed only in implementation code, a change in one area can force work across the whole system. A new user-interface technology can become a rewrite of business rules. A change to a business process can become tied to a specific framework. This makes it difficult to see what investment is being protected and what is being replaced.
The alternative is to identify the concerns separately from the start:
| Area | Definition | Typical reason it changes | Example |
|---|---|---|---|
| System gist | The business meaning of the system: its concepts, relationships, rules, and intended behavior. | The organization changes how it works or learns more about its domain. | An order must have order lines; an order line refers to a product; an order cannot be completed until its required information is present. |
| Modernity | The technical means used to build, execute, secure, maintain, and deliver the system. | Platforms, development techniques, operational requirements, and available technologies change. | The system is delivered through one client technology today and another technology later. |
| Fashion | A currently preferred appearance or interaction style. | User and market preferences change. | A screen is rearranged or styled to match the current expectations of its users. |
These areas affect one another, but they are not the same problem. Treating them as the same problem makes decisions harder to explain and systems harder to evolve.
Put system gist in a durable form
For a business building systems to support and automate its work, system gist deserves explicit ownership. It contains the organizationâs knowledge of what it does, what information matters, and which rules govern that information. This is structural knowledge that should be understandable, discussable, and actively maintained.
Prose requirements and implementation code both have limitations for this purpose. Prose can be interpreted in different ways. Code is detailed, but it also contains technical choices and the style of the team that wrote it. Models provide a middle ground: they can describe the system more precisely than prose while remaining easier to discuss than implementation code.
In model-driven development, the model is a machine-readable representation of the system gist. A model executor turns that model into a running system for a particular technical environment. MDriven is used to model, prototype, and execute business applications, while allowing a system to progress as its delivery requirements change.
Example: keep an order rule separate from its delivery
Consider a business system that handles customer orders.
The system gist includes:
- The concepts Customer, Order, Order Line, and Product.
- The relationships between those concepts.
- The rule that an order is not completed until its required information is present.
- The information users need to review and maintain an order.
Modernity includes:
- The technology used to execute and deliver the application.
- The database and operational environment used to store and run it.
- The techniques used to meet maintainability, security, efficiency, and deployment requirements.
Fashion includes:
- Whether an order screen uses a particular layout or visual style.
- Which interactions users currently expect when reviewing order lines.
If the organization changes the completion rule, that is a system-gist change. If the organization wants the order screen to look different, that is normally a fashion change. If the delivery technology must change, that is a modernity change. Identifying the category first helps the team change the right thing and avoid treating every request as a rewrite.
Make decisions in the right area
Before choosing a solution, classify the question you are trying to answer.
- State the requested change in business terms.
- Ask whether it changes a business concept, relationship, rule, or intended behavior. If it does, it is a system-gist question.
- Ask whether it concerns execution, delivery, maintenance, security, efficiency, or the technical lifespan of the solution. If it does, it is a modernity question.
- Ask whether it concerns a currently preferred appearance or interaction. If it does, it is a fashion question.
- Record the decision in the representation that belongs to that area. Keep business meaning in the model rather than hiding it in technology-specific code or presentation choices.
For example, âusers need to see an orderâs lines while editing an orderâ identifies information and behavior that belong to the system gist. The exact visual arrangement of those controls is a presentation concern. ViewModels can describe available data, valid values, and selection lists, and can include placement hints without becoming a complete presentation design. This lets the business information remain available even when the front end changes.
Why the separation matters
A systemâs business meaning evolves with the business it supports. Its technology changes in response to forces outside the business: platforms change, development communities adopt new techniques, and technical requirements move. Fashion changes at yet another pace.
Keeping these concerns apart gives each area room to evolve:
- You can discuss and improve the business solution before it becomes expensive implementation code.
- You can change technology without automatically redefining the business concepts and rules.
- You can change presentation choices without confusing them with business requirements.
- Stakeholders can review the system gist without needing to read technology-specific code.
- The organization retains a usable description of its system instead of relying only on the memory of individual developers.
This is not an argument that modernity is unimportant. Technical architecture affects maintainability, security, efficiency, usability, delivery, and the projected lifespan of a system. It should be handled carefully, using the appropriate technical techniques. The point is to avoid allowing modernity or fashion arguments to silently determine business meaning.
Avoid common confusions
| Confusion | Better question | Example |
|---|---|---|
| âWe need a new interface, so we must rebuild the application.â | Which part is a delivery change, and which part is business behavior that must remain unchanged? | Keep the order concepts and completion rule; reassess the delivery technology separately. |
| âThe current framework makes this business rule difficult, so the rule must be wrong.â | Is the business rule correct independently of the current implementation technique? | Confirm the order-completion rule with stakeholders before changing it for technical convenience. |
| âUsers prefer this layout, so it is a domain requirement.â | Is the request about information and behavior, or about its current presentation? | âShow order linesâ is a data requirement; the chosen screen arrangement is a presentation decision. |
| âOnly developers can explain how the system works.â | Where is the system gist represented and maintained? | Use the model as a shared representation that stakeholders and developers can review. |
Model-driven development and MDriven
Model-driven development develops system gist in its own machine-readable format and uses a software machine to turn that gist into a complete software system that meets modernity requirements. This approach aims to avoid entangling concerns that change at different intervals.
MDriven supports this approach by making the model a working part of the system rather than a document that is abandoned after implementation begins. You can use MDriven to model information and behavior, test ideas, and continue toward a finished system. Read Training:What is MDriven for an introduction to the platform.
The model does not remove the need for technical decisions. It makes the boundary clearer: retain the business meaning in the model, then select or evolve the execution and delivery approach as modernity requires. The same principle applies to presentation: describe the information and behavior needed by users, then apply the current front-end approach without redefining the system gist.
A practical review for every change
Use these questions when reviewing a requirement, defect, or modernization proposal:
- What business concept, relationship, rule, or behavior is affected?
- Is this a system-gist change, a modernity change, a fashion change, or more than one of these?
- Which part of the model must remain true regardless of delivery technology?
- Which technical requirement must be met, such as maintainability, security, efficiency, or deployment?
- Which presentation choice can change without changing the business meaning?
- Can stakeholders understand and confirm the business decision without reading implementation code?
Answering these questions does not eliminate change. It makes change deliberate. The team can evolve the business system where the business needs it, modernize the technical solution where technology requires it, and update presentation where users need itâwithout confusing one kind of work for another.