Execution Units


Activities can be split into units whose execution is bound to a single resource or is to be performed in continuity.

Execution unit: continuous change and single resource (Gerhard Richter)


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.

(a) three symbolic activities, single execution unit; (b) activities executed independently.

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.


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:

  1. 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.
  2. 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.
  3. 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.

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).

Transient representation of execution units: trucking, repairs, and invoicing can be executed separately.


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.

Synchronization semantics: flow and time; within and across execution units.

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.


2 Responses to “Execution Units”

  1. Putcha V. Narasimham Says:

    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?


  2. caminao Says:

    I make a distinction between requirements and mechanisms, my argument is about the former, your argument is about the latter.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


Your content with a new angle at WordPress.com

IT Modernization < V.Hanniet

About IT Modernization

IT Modernization < V. Hanniet

software model driven approaches

Caminao's Ways

Do systems know how symbolic they are ?

%d bloggers like this: