Architecture in the simplest terms is something which allows many people to gain a shared understanding. I have found that this perspective on architecture maps to traditional construction architecture as well as the various fields of architecture which exist within Information Technology and Enterprises in general.
Reality based architecture is the idea that architecture can be based in reality. A very effective way to create shared understanding is to create a model of the thing we are trying to understand. Models are simplified representations of the real thing. A model of reality makes it easier to see the whole thing and understand it.
It seems rather obvious that architecture should be based on reality so why bother writing about it? In traditional architecture, of buildings, a blueprint represents the real thing intended to be built. However, in software architecture the models which are often created are meta-models. A class in UML represents a type, categorization, or class of objects, but not the actual objects themselves. A class diagram show relationship between classes which actually represents the relationships between actual objects that is allowed and may occur. It is not until the software runs that objects and relationships are created. The same kind of meta-model approach is used for Entity-Relationship data modeling. Entities represent Tables in a database which is the tabulation of records of a type, categorization, class, or entity. The records actually represents the real instances of an entity.
The software meta modeling practice has heavily influenced architecture practices in both Information Technology and Enterprise Architecture. The meta-model approach is great for capturing and describing patterns and reference architectures.
The meta-model approach is not as effective when we need to understand the current state of an enterprise, business unit, org unit, IT system, business system, team, project scope, or program scope. This is where a reality based architecture approach which models the actual, “real”, things is more effective.
A simple litmus test to figure out if an architectural artifact is reality based or if it is a meta-model is to ask if it is specific to an enterprise, business unit, system, etc. If it is specific to a context then it is likely a reality based architectural artifact. If it is an artifact which easily could be used for a different enterprise, business unit, or system then likely it is a meta-model architecture artifact.
I am not arguing that meta-model architecture artifacts are not valuable. There are many situations where it is the best approach. As mentioned earlier it is great to capture and describe patterns. However, if the goal is to describe the current state of a real thing or to describe the desired, tangible outcome of a project then using a reality based architecture approach is more effective when it comes to creating a shared understanding across the greatest number of people. When a meta-model is used, people have to map the meta-model to their specific context and situation. Mapping an abstract meta-model to a real situation and context comes easy to some and hard to others. The point is a meta-model is not as effective in creating a shared understanding for the greatest number of people when describing existing things or tangible desired outcomes.
PrimaryScape was to a great extent created to make it easy to create simple, visual models of reality. The key lies in its ability to show the complete picture, processes in context with information and systems along with teams.