You can use this page to decide where to keep the lasting value of a business support system: in the business modelâthe Gistârather than in the technology used to run it.
The value is in what makes your business different
A key blank can be used to produce many keys. The cuts in the finished key make it fit one particular lock. Two finished keys can look similar, but their different cuts are the reason each key exists.
A business works in the same way. Many organizations use similar technology, employ similar roles, and perform similar activities. What distinguishes one organization is the specific combination of knowledge, decisions, rules, information, and processes it uses to do its work.
For example, two distributors may both receive orders, reserve stock, deliver goods, and invoice customers. One may allow a customer to reserve stock only after a credit check; the other may prioritize stock for contractual customers. Those differences are business knowledge. They should be explicit in the system that supports the business.
If your system does not preserve the parts of your work that are different, it does not preserve the reason the system is needed.
Gist and Modernity
MDriven distinguishes between two things with different lifecycles:
| Term | Meaning | Example |
|---|---|---|
| Gist | The business-specific description of what the system must know and do. It includes the model of business concepts, their relationships, and the rules that govern them. | A model that describes Customer, Order, and StockReservation, together with the rule that a reservation requires an approved customer. |
| Modernity | The technology used to execute and present the system at a particular time. | The runtime or user-interface technology through which users work with orders and reservations. |
The key blank represents Modernity. It is necessary to make and use a key, but it does not contain the distinguishing pattern. The cuts represent the Gist.
In MDriven, you describe the Gist with UML and declarative rules such as OCL. The result is a machine-readable and human-readable description of the business. It is the artifact you maintain as the business changes.
Keep different lifecycles separate
Business knowledge and technology do not change for the same reasons or at the same rate.
- A business rule changes when policy, market conditions, regulations, or working practices change.
- A process changes when the people performing the work find a better way to reach a goal.
- A technology choice changes when an organization replaces a runtime, presentation technology, or other technical foundation.
Do not hard-fix artifacts with these different lifecycles together. If a credit-approval rule is embedded in technology-specific implementation, changing either the rule or the technology requires finding and reworking that implementation. If the rule is part of the Gist, you can discuss and change the business rule at the level where it belongs.
For example, a business may change its rule from âapprove every new customer before an order can be releasedâ to âapprove only orders above a defined amount.â That is a change to business behavior. Model and review the rule as part of the Gist; do not treat it as a reason to redesign the technical foundation.
Getting to the bottom of the Line of Business Application explains why the business description is the central artifact for a line-of-business application. For the wider distinction between the business content and its changing technical and presentation concerns, see Fashion, Gist, and Modernity.
Model the business so you can change it
Unlike a lock, a business does not stand still. Its information, processes, rules, and priorities evolve. The useful question is not whether the system will change; it is whether you can identify, explain, and make each change in a controlled way.
Use the Gist as the shared description of the current business reality:
- Work with representative domain people to identify the people and events that trigger work, the goals they pursue, and the high-level processes they follow.
- Describe the information involved in each process as a UML model. Keep each model readable by focusing on the information relevant to the process.
- State the business rules declaratively, using OCL where appropriate, so that the rule is visible and can be reviewed with the model.
- Run and review the resulting system behavior with domain users. Update the Gist when reality changes.
For example, an order-release process may involve a customer, an order, order lines, stock, and a release decision. A domain group can identify the process and its steps; the UML model captures the information; and an OCL rule can express a constraint such as the requirement that an order must have at least one order line. Each part remains connected to the business meaning it supports.
For a workshop-oriented approach to finding this knowledge, see Knowing nothing, where to begin.
Own the business description
The Gist is valuable because it does two jobs at once:
- It records the structured understanding of the information and rules the business currently uses.
- It drives the implementation of the business support system.
This gives domain experts and technical staff a common language. Rather than discussing an undocumented interpretation of a requirement, they can examine the same process, model element, or rule and decide what must change.
A complete business description is also useful when the implementation technology changes. The aim is to carry the Gist forward to another compatible Modernity rather than recreate the business understanding from technology-specific code or configuration. MDriven has moved its technical foundations over time, from Win32, ASP.NET, WPF, and Silverlight to HTML5; the principle is that the business pattern should outlive a particular technical blank.
What to prioritize
When planning work on a business support system, prioritize the artifacts that express business-specific knowledge.
| Prioritize | Do not confuse with the primary business asset |
|---|---|
| A clear UML model of the information and relationships the business uses | The technical platform by itself |
| Explicit rules that can be reviewed and changed | Rules hidden in technology-specific implementation |
| Processes validated by the people who perform them | Assumptions derived only from existing documentation or technical staff |
| Continuous refinement as business reality changes | A one-time model that is left behind after implementation |
Technology remains necessary: it is how users access and execute the system. But technology alone does not make a system fit your organization. The Gistâthe pattern of business knowledgeâis what makes that fit possible.