In today’s post, we are going to dive deep into what it means to have a “clean” model and share some of the principles that guide PMC when completing models for our customers. Whether you are working in traditional CAD or a full digital twin BIM a clean model will function well on your project, minimizing the time taken to rework data as the project progresses.

Why a Clean Model?

A Model is clean if it can be understood easily – by everyone on the team. With understandability comes readability, changeability, extensibility, and maintainability. All the things needed to keep a project going over a long time without accumulating up a large amount of technical debt.

Clean

Composing a clean model from the start in a project is an investment in keeping the cost of change as constant as possible throughout the lifecycle of a design and construction project. Therefore, the initial cost of change is a bit higher when developing a clean model (grey line) than quick and dirty design (black line), but is paid back quite soon. Especially if you keep in mind that most of the cost has to be paid during the maintenance of the model. Unclean models result in technical debt that increases over time if not refactored into a clean model. There are other reasons leading to Technical Debt such as bad processes and lack of documentation, but unclean models are a major driver. As a result, your ability to respond to changes is reduced (red line).

In Clean Models, Errors Cannot Hide

Most errors and omissions are introduced when changing existing models. The reason behind this is that the designer changing the model cannot fully grasp the effects of the changes made. Clean models minimize the risk of introducing errors and omissions by making the model as easy to understand as possible.

Rules to develop clean models

General

Follow Standard Conventions +
In house, client-specific, design guidelines (check them with tools)
Keep it Simple, Stupid (KISS) +
Simpler is always better. Reduce complexity as much as possible.
Boy Scout Rule +
Leave the campground cleaner than you found it.
Root Cause Analysis +
Always look for the root cause of a problem. Otherwise, it will get you again and again.

Design

Keep Data at the Highest Level +
Add data to objects at the highest level possible for the type of data being added. If you have a type-level attribute, apply it at the type level never the instance level.
Don’t Be Arbitrary +
Have a reason for the way you structure your model, and make sure that reason is communicated by the structure of the model. If a structure appears arbitrary, others will feel empowered to change it.
Be Precise +
When you make a decision in your design, make sure you make it precisely. Know why you have made it and how you will deal with any downstream consequences.
Structure over Convention +
Enforce design decisions with structure over convention. Naming conventions are good, but they are inferior to structures that force compliance.
Prefer Polymorphism To Static Objects +
Model objects should be dynamic. Changes to design should seldom involve the deletion of objects, instead, the object types should support rapid change.
Separate Complex Geometry +
Do not add objects to the model that add no value to the others on the project. Keep large, heavy objects isolated within there own files.
Misplaced Responsibility –
Every object within a model must have an owner. Each object must exist only within a single model that is controlled by the object owner.

Principles

Loose Coupling
Two objects, components, or entities are coupled when at least one of them uses the other. The less these items know about each other, the looser they are coupled. A component that is only loosely coupled to its environment can be more easily changed or replaced than a strongly coupled component. An example of a strongly coupled component is a Revit level object, an example of a loosely coupled object is a Revit annotation. Changing a level will have global implications for the project while changing an annotation will at most affect only one other object within the project.
High Cohesion
Cohesion is the degree to which elements of a whole belong together. Models should be organized such that model elements have as high of cohesion as possible. High cohesion can take the form of how objects are hosted, walls and doors associated to the correct level, or what model the objects are placed in.
Containment
Models are contained when all contributors to a design connect to a single source of data. When the containment is lost multiple copies of the same data exist and become disparate in their content.
It is Easy to Remove
We normally design buildings by adding, extending, or changing features. However, removing elements is important so that the overall design can be kept as simple as possible. When a block gets too complicated, it has to be removed and replaced with simpler blocks.

Smells

Rigidity –
The model is difficult to change. A small change causes a cascade of subsequent changes.
Fragility –
The model breaks in many places due to a single change.
Immobility –
You cannot reuse parts of the model in other projects because of involved risks and high effort.
Viscosity of Design –
Taking a shortcut and introducing technical debt requires less effort than doing it right.
Viscosity of Environment –
Loading, editing, and other tasks take a long time. Therefore, these activities are not executed properly by everyone and technical debt is introduced.
Needless Complexity –
The design contains elements that are currently not useful. The added complexity makes the model harder to comprehend. Therefore, extending and changing the model results in a higher effort than necessary.
Needless Repetition –
The model contains lots of elements (graphical or non-graphical) duplication: exact element duplications or design duplicates (doing the same thing in a different way). Making a change to a duplicated piece of data is more expensive and more error-prone because the change has to be made in several places with the risk that one place is not changed accordingly.
Opacity –
The model is hard to understand. Therefore, any change takes additional time to first re-engineer the model and is more likely to result in defects due to not understanding the side effects