A Sense of Place

"Where things are" or "where things will be" *is* Operational Modelling - do we put the system's data close to the user, where performance and availability will be good, or do we put it somewhere central, making security and systems management easier?  Once these business driven(!) decisions are made, then (and only then) can the system's infrastructure be designed - for example ensuring distributed data is up to date, or backup and recovery software is implemented.

(Yes, I know I am being idealistic - when was the last time you could choose where to put operational data in order to ensure the right levels of business performance?!)

(This linkage between solving business requirements (by appropriate placement of the application and its data) and the consequential infrastructure systems design is also present in the functional viewpoint, hence the horizontal application/infrastructure split across both left and right hand-sides of my box.)

And it's this sense of place that's the 4th issue with LEGO.  In the analogy, we'd be constructing models from Lego bricks - and of course each brick has to be somewhere.  The whole brick in the same place (unless you decide saw a 4 * 2 in half!).  But things are different with IT Systems...

...because in IT system's design we might think we place components (that may be based on ABBs),  but in fact we do NOT place them "whole"(*) - we make separate placement decisions for the things from which these components are composed:

• Where to store (or where is) the data that each component owns?  Maybe all of it is in one central or distributed database, for all of the system's components?
• Where will (or where are) the components' functions run?  Some might run centrally, others on the user's workstation?   Or might some components be configured as a client-server configuration?
• Where will be (or are) the components' runtime executables stored?  (Their .exe's. .dll's, and so on).  All in one file on the same machine as they run, or as separate files on a file server somewhere else?

All three of these places may of course be different places; and, to cap it all, all may be somewhere completely different from the place where the user accesses the component.  So OM has to model all four places, in order for us to understand the implications of "distribution" - how will the infrastructure connect the execution of a component with its data?  What will the operational characteristics of that distribution be - good enough for the user's required response time, throughput, or security and availability?

So operationally an ABB is not a monolithic thing after all - it may be a cohesive, encapsulated and loosely coupled atomic building block when looked at through one of the functional viewpoints - after all, this togetherness of the four elements is the major abstraction of the functional side of my box; but the moment we bring back in to our thinking the major "real world" issue of place, we need to expose the component's insides - not only does that need Operational Modelling, it also needs us to modify our LEGO analogy for the fourth time, to allow the "atomic ABBs" to be split up into their constituent parts.

Footnote: 
What do we call these "constituent parts" of our components?  What "are" they?  Whatever they are, we need to explicitly model them so that they can appear on Operational Views.  And to model these "units of deployment"  they probably need a (collective) name...  How about "Deployment Unit"?  We'd then be able to model Data Deployment Units (DDUs), Execution Deployment Units (EDUs), Installation Deployment Units (IDUs) and Presentation Deployment Units (PDUs)!

(*) this does not stop many people, often very experienced system designers, claiming they do place components into the "real world".  It's only when you quiz them, hard, that it transpires they mean they place an aspect of the component. Most often, I discover they mean the components' EDUs, but sometimes it's where their IDUs will be...