Placement

OK, so what's the difference between "a sense of place" and "placement"?

A great question, and one we did not know to ask until only a few years ago.  It all comes down to...

...multiplicity

We don't necessarily place a Deployment Unit (DU) just once, in one place.  There may be more than one "instance"(*) of a DU on an operational view - it is placed multiple times.  In fact, experience tells us that if at least some DUs do not appear several times, then the design is at best incomplete, and at worst poor or unworkable.

(*) More accurately, we have more than one "representative instance", since it may be that there are many instances of each place were the DU is deployed.

For example...

• The Data DU associated with a Home Shopping application's "Catalogue" component might be "The Catalogue". Naturally, given its reach (out to the home shopper) and range (all home shoppers), one might decide to deploy it onto (one) central server.  But does this decision ensure good performance or availability for all users?  What if the customer wants to build an order, but their internet connection is down?  The answer may be to keep a copy of the catalogue on each and every customer's workstation.
  
• It may be appropriate to run the "Catalogue" component's Execution DU on several internet servers for some home shoppers (such as those working in a Call Centre, taking orders by phone as a proxy for the real customer) - because communication is sufficiently reliable, available and secure.  But for others - such as each real customer working on their own device, it may be better to run the same code locally; for the same reasons as they have a local copy of the catalogue.

In the first case, we have two instances of the catalogue (master and copy) in two different representative places (possibly called "Regional Data Centre" and "Home"); and the second two (identical?) instances of the catalogue's execution  could be in places "Call Centre" and "Home".

Of course both design decisions can introduce significant and often costly infrastructure design challenges, which in turn means the business benefits of such placement centric design decisions need to be sound.

Other things being equal, then, the functional DU, representing an aspect of a component, has a single specification - if it's a Data DU then we may wish to know its size (records or Gb) and volatility (some measure of frequency of change); whereas for an Execution DU we should be interested in transaction rates or concurrent users.  But these single specifications are abstractions, approximations to the real world - maybe a decision is made to update the copy of the operational DDU less frequently than it changes: so there are now two specifications for the same DU...

In other words, the operational DU is different from the functional DU - both have a sense of place, but only the operational DU has placement - it is somewhere and hence more "real world".  But what to call it?  If we were to call the places in which it is deployed "Locations", then a natural name would be "Located DU", and there's usually (in anything other than the simplest designs) more than one Located DU for each DU.

So the fifth and final shortcoming of the LEGO analogy is...

...IT System ABB based model elements can be in more than one place, but a Lego ABB cannot.