Reflection: reality v the physical world

Aren't these the same thing?  Isn't the physical world reality?

In the same spirit as non-engineers are happy to interchange "stress" and "strain", then yes they are.   But we're not lay people - we are IT System designers, who recognise a more precise way of observing the world...

• Reality is related to abstraction - how "realistic" is the model you are constructing in order to understand and communicate your ideas about the IT System?  Put otherwise, how much information are you modelling?  More "content" = more "real".
  
  We've already seen this in action - the functional dimension of my box captures less information than the operational dimension - it is more abstract because it ignores (or you may wish to think of it as simplifying) great swathes of detail associated with place - which is no bad thing when you are focused on the cohesion, coupling and encapsulation of your "lumps of function and data".  But on the other side of the box, all of this extra stuff is modelled, because we are now looking deeper into more realistic views of the system's model: operational modelling is more realistic than functional modelling.
  
  Critically, it vital to realise that "the real world" can be modelled either logically (as specifications of what the model elements are required to do) or, with equal validity, physically...

• Because  thinking about the physical world means thinking about actual things, whatever the level of abstraction - in other words, 
• • Physical things can be equally associated with the functional or operational sides of my box; for example, a functional physical thing might be a software package from vendor "TBO" composed of modules A, B and C; whereas an operational physical thing would be a located PC model XYZ from manufacturer ABC running parts A and B of that package.
    
  • Physical things may be at (or span) the application and/or infrastructure levels (a specific version of a vendor's FTP package is infrastructural).
  
  In all events, modelling physical things means making decisions on (or observing previous decisions on) the implementation of a logical specification.  E.g. choosing a broadly based, fully integrated software package TPO for all back office functions is a functional physical decision, or choosing a PC model XYZ from vendor ABC to implement the "Regional Application Server" located node is an operational physical decision. 

Sadly, it is one of the most common mistakes I see made by systems designers - freely interchanging the two concepts of "physical" with "realistic", usually only using the qualifier "physical" to distinguish any and all the views they may create that are not "functional" - if it's not a component view then it must be physical...  As a common mistake it can be extremely disruptive, in two distinct ways

1. Because it represents a switch of thought across two dimensions of my box - a functional systems designer working with logical functional views would expect an operational system designer to create more realistic-physical operational views... and one thing I've learnt as an engineer is "change one thing at a time"!
   
2. Because it completely dismisses (jumps over) the logical operational view (more realistic, not yet physical), which is THE view used to balance and optimise placement decisions, firstly of logical located (application) DUs and secondly the operational functionality needed in the infrastructure to support these placement decisions.

So, in a nutshell, relating these two notions to my box:

• "Reality" is the right side - OM is more "real" than CM, whether thinking logically or physically; application or infrastructure
  
• "Physicality" is the back plane, addressing both functional and operational implementations of logical specifications, at both application and infrastructure levels.