You can use a Theoretical Best Model (TBM) to describe the business reality your system must support, review that description with domain experts, and evolve it as the business changes.

Reality and the Theoretical Best Model

Reality is the way a business domain actually works: its concepts, rules, responsibilities, information, and processes. A Theoretical Best Model (TBM) is the best useful approximation of that reality that you can describe at a given time.

TBM is not a claim that the model is complete or permanent. A business changes, and some real-world complexity may be outside the scope of the system. The goal is to model the parts of reality that matter to the business support system and to make those choices explicit.

For example, a delivery business may distinguish a Delivery, a Recipient, and a Delivery Status. If its competitive process requires a delivery to be reassigned while it is in transit, that rule belongs in its TBM. If the business does not need to model the color of a delivery vehicle, that detail can remain outside the TBM.

Why the model must follow the domain

Competing businesses can appear similar while using different terms, rules, and ways of working. Those differences can be central to how each business competes and evolves.

A domain-oriented model preserves the language and distinctions that matter to the people running the business. This is consistent with domain-driven design, where the model uses the terms and definitions of the domain rather than technical or generic substitutes.

For example, two businesses may both handle customer requests. One may treat a request as a Case that passes through regulated review states; another may treat it as an Order that can be fulfilled immediately. Replacing both concepts with a generic record may hide the rules that make each business different.

Standard systems and the translation layer

A standard system is based on a standard model: the supplier's general description of a domain. When you choose such a system, implementation often requires a translation between your TBM and that standard model.

This creates three distinct artifacts:

Artifact	Owner or source	Purpose
TBM	The business and its domain experts	Describes the business reality that the support system must serve.
Standard model	The standard-system supplier	Describes the concepts and behavior supported by the chosen standard system.
Translation layer	The implementation team working for the business	Maps the TBM to the standard model through configuration, adaptation, or other implementation work.

For example, your TBM may define a Delivery with a business-specific set of status changes. A standard system may instead use a generic Shipment and a fixed workflow. The implementation must translate the business-specific delivery concepts and rules to the supplier's shipment concepts and workflow. The translation is an artifact in its own right; it needs review, ownership, and maintenance.

Manage change across all artifacts

The three artifacts can change independently. Treat a change in any one of them as a reason to review the relationships between all three.

When business reality changes

When the domain changes, first update the TBM so it continues to represent the intended reality. Then assess whether the translation layer still maps the TBM to the standard model.

1. Identify the changed business concept or rule.
2. Update the TBM and review it with the relevant business functions.
3. Check the translation layer for assumptions that no longer hold.
4. Update the translation where it can absorb the change.
5. If the standard model cannot support the new TBM, decide whether to change the standard system, accept a documented limitation, or choose another approach.

For example, if deliveries can now be reassigned after dispatch, the TBM must describe that new lifecycle. A previous mapping may assume that dispatched shipments are immutable. That mapping must then change, or the limitation must be made explicit.

When the standard system changes

A supplier can update its standard model as part of normal product maintenance. Even when business reality has not changed, that update can invalidate the translation layer.

1. Identify the supplier change that affects the implemented model.
2. Compare the affected standard-model concepts with the existing translation.
3. Verify that the current TBM is still represented correctly.
4. Update and test the translation before adopting the changed standard model.

The important point is that a working translation is not permanent. It represents alignment between specific versions of the TBM and the standard model.

Decide where standardization is appropriate

A business can choose to adopt the standard system's model as its working reality. This can reduce implementation effort because it removes or reduces the translation work. It can be a reasonable choice for processes that are not central to how the business earns, competes, or differentiates itself.

For core business processes, forcing the organization into a generic model can constrain the ability to refine those processes later. The organization then depends on the supplier's model for changes to an area that may be strategically important.

Use the following questions when deciding:

Question	Implication
Is this process central to the business's competitive ability?	Maintain a TBM that expresses the business-specific concepts and rules before selecting or adapting a system.
Is this a supporting, non-core process where standardization is acceptable?	Adopting the standard model may be a deliberate trade-off that frees attention for core processes.
Can business experts explain and review the model?	Keep the TBM human-readable and use the domain's own language.
Can the model evolve without reinterpreting undocumented implementation decisions?	Maintain the TBM and any translation as explicit artifacts.

Build and maintain a TBM

TBM constitutes the functional demands on the desired support system. Establish it before comparing implementation candidates, so that selection is based on the business need rather than on the limits of a preselected system.

An architect function often coordinates the model, but the model must be reviewable by the high-level business functions that use and govern the supported domain.

1. Describe the important domain concepts as classes and their relationships.
2. State the rules that govern valid data and valid changes.
3. Use the domain's terms consistently so that business experts can review the model.
4. Try the model with representative data and scenarios.
5. Refine the model and the views used for specific business needs as users provide feedback.
6. Revisit the model whenever the domain, its rules, or its priorities change.

In MDriven, you can describe data concepts as classes, relationships as associations, and rules for change with state machines. You can then create objects that follow those descriptions and refine views for specific use cases. See Build Enterprise Information Systems for the iterative modeling approach.

Keep model error visible and planned

At any time, there can be differences between:

• reality and the TBM;
• the TBM and a translation layer; and
• a translation layer and a standard model.

These differences are not always avoidable. The risk comes from leaving them unmanaged. Record the known difference, its business consequence, who owns it, and the planned action to reduce or accept it.

For example, if a standard system cannot represent reassignment after dispatch, do not let that fact remain an undocumented implementation detail. Record that the system differs from the TBM, identify the affected users, and decide whether the limitation is temporary, acceptable, or requires a change.

This discipline lets leadership decide where the business accepts compromise and where it must preserve its ability to evolve.

Use a model that people and machines can read

A TBM should be clear to human readers and precise enough for machine execution. MDriven bases its modeling strategy on open standards including UML and OCL from OMG.

OCL (Object Constraint Language) expresses rules over the model. MDriven can execute model expressions and actions while you prototype and inspect model behavior. For example, an action can assign an address with first.Address:="youraddress"; the assignment uses :=, while = tests equality. See OCL Editor, system prototyper and ViewModel for an example of executing and debugging model behavior.

A ViewModel defines the information and structure needed for a particular view. It keeps view-specific needs separate from the domain model while allowing the runtime to follow the declared model. This supports an iterative process: change the business description, try it with data, review the resulting behavior, and refine it.

Automation follows understanding

The primary value is the TBM: it is the shared description of what the business does and what the support system must do. Once the required behavior is expressed clearly, implementation can increasingly be treated as an engineering transformation rather than repeated interpretation of requirements.

MDriven executes the model at runtime. The runtime follows the UML model, including the rules expressed in it, rather than requiring the same business behavior to be re-created as ordinary program code for each client. This means that a model can remain the central artifact as the system is refined.

Automation does not remove the need for a human-readable model. Business leaders, domain experts, and organizations subject to inspection or regulation still need to understand and discuss what the domain does. Regardless of how a model was created, it must make sense to human reviewers.

See also

• Documentation:Model Driven
• Documentation:Build Enterprise Information Systems
• Documentation:Learn OCL
• Documentation:OCL Editor, system prototyper and ViewModel
• Documentation:Fashion Gist and Modernity