Scope
Activities can be split into units whose execution is bound to a single resource or is to be performed in continuity.
Objectives
Execution units are the building blocs of business processes. Symbolic units take into account flow dependencies, i.e constraints on objects being processes; actual units take into account time dependencies, i.e constraints on execution. Both kinds of dependencies should be solely defined by functional constraints, independently of technical platforms that would have to support them.
System architectures are first and foremost constrained by their coupling with business contexts, and those constraints cannot be defined if processing units are not properly identified. That must take into account (1) the activity concerned, (2) a time reference, and (3) its footprint.
- Activities are identified by a triggering event, which is necessarily issued by an agent since it is the only link between systems and contexts.
- Being active and physical, agents are necessarily set into locations; as a consequence the triggering of activities are also located within address spaces under the control of single clocks.
- Given the initial context and the set of potential execution paths, the activity footprint is the set of objects possibly affected, directly or indirectly, until the completion of the activity .
At requirement level execution units are usually introduced as UML use cases.
Principles
Obviously activities can cut across several locations hence, as far as architecture is concerned, the point is to decompose them into execution units, each set with their own requirements regarding business resources and control. For that purpose one can reformulate Aristotle’s three unities:
- Unity of action: a performance should have one main action triggered by a single event initiated by a single primary actor. Subplots, if any, may summon the collaboration of secondary actors but they must return to the main plot after completion. Otherwise system architects would be kept in ignorance regarding possible execution dependencies.
- Unity of place: a performance should be located into a single physical space where all resources can be obtained directly, and should not depend on activities from other locations. That is a necessity if functional architectures are to be managed independently of technical ones.
- Unity of time: a performance should be timed by a single clock under which accesses to all resources can be synchronized, i.e it should not depend on events timed by other clocks. That is a necessity if innards and synchronization of business processes are to be managed independently of choreography and orchestrations supported by communication architectures.
These dimensions are used to characterize how execution units are to be anchored to the relevant context: organization, persistency, and synchronization.
With regard to organization, each execution unit must be carried out under the authority of a single agent, usually represented by a swim-lane.
As for persistency units, the representation of execution units must be anchored to activities identified individually, i.e whose execution can be timed by physical clocks (cf synchronization dependencies).
Synchronization
Execution units can be structured into local components using standard operators, or different execution units can be combined using functional connectors; in that case, execution dependencies between activities should be specified depending on:
- Locality: whereas local synchronization within execution units can be controlled under a single clock, dedicated mediating mechanisms are needed if synchronization is to be achieved between execution units.
- Nature: if functional and technical architectures are to be set apart, one should distinguish between symbolic and actual execution dependencies. The former deal with targeted objects and flows, the latter deal with physical timings.
Symbolic and actual constraints can be described as synchronization dependencies or expressed as rules. Their distinction is pivotal when architectures are considered because each kind of constraints calls for different kinds of solutions. That should be the basis of workflow patterns.
I make a distinction between requirements and mechanisms, my argument is about the former, your argument is about the latter.
The unity principle is great and its application here is useful and also great. Very nice of you to have used it aptly.
About trigger and who triggers FIRST we have a disagreement. Let me see if this helps resolving it.
One interpretation of synchronization of two different activities is that some specified actions, one from each activity (a series of actions) occur at the same time with ref to a single clock. There after the actions of different activities get locked to that clock. If the the timing drifts for any reason, the lock is lost and has to be reestablished. (Phase locked loops).
If two different activities do not have common clock but are mutually dependent, they need to have “lock-step” arrangement (time lapses are ignored).
Are there other cases of synchronization?