Scope
To be of any use to the business concerned, systems must know what’s going on, and remember what has been done as well as what remains to be done. For that purpose systems must keep a symbolic representation of business concerns. And that may bring about all kind of objects.
On the business side objects can be physical or notional, and physical ones can be managed individually or lumped. On the system side symbolic objects can not only represent business ones but may also stand for running activities. That distinction between business objects and system symbolic representations is at the core of system modelling.
Business Objects
Business objects can be physical or customary.
Taken literally the distinction between actual and symbolic objects can be somewhat confusing since, eventually, symbolic representations will have to be physically implemented as system components. Moreover, documents are originally both physical and symbolic, and customary agreements may not even materialized by a document. Yet, understood in the context of system functionalities, the point is to set apart objects in business contexts from their system counterparts: actual business objects stand on their own, symbolic ones stand on their own, symbolic representations stand for actual or symbolic business objects.
For instance:
- Portraits are are physical representations of physical objects.
- Works of art are physical business objects.
- Handshakes are symbolic events not necessarily associated with symbolic representations.
- Stone tablets are symbolic representations with physical implementation, but are not business objects on their own.
Objects and Functional Architecture
From an architectural perspective, two questions must be asked:
- Are object representations to be anchored to their business counterparts. For that purpose objects must be persistently identified on their own, and their states managed. That’s not much of a problem for transient objects or snapshots, which therefore don’t incur significant coupling constraint between system and context. Things are different for persistent representations whose identity is to be continuously and consistency managed along time and across activities. A special case is to be made for external physical objects to be dealt with by the system even if they are not represented.
- Are objects’ identity defined by their physical or customary features. Mapping physical objects to their symbolic representation bears specific architectural constraints regarding the coupling between system and context. That’s not the case for customary objects whose identity is by nature documental. A special case should be made for binary objects, simultaneously physical and documental.
It is worth to be noted that at any given time legacy systems appear as active objects. Moreover, as far as context objects are described as black boxes, active objects can be symbolic systems, mechanical devices, or human agents. Things may become clearer when more can be known about communication channels supported: symbolic, analog, digital.