How Does an Enterprise Operate?
Part 5: Composing Transactions

In a previous blog, I showed that every business conversation follows a generic pattern called the transaction pattern. This pattern deals with the ‘happy’ flow, but also with disagreements (discourse) and cancellations (revocations). In the real world, however, a transaction almost never stands on its own; multiple transactions constitute a whole. For example, when you order some coffee, a counter transaction ‘payment’ will be started by the employee that brings you the coffee. Another example is that in order to produce a cappuccino, milk froth needs to be produced; frothing the milk may be considered a sub transaction of which the result is needed to create the while product, viz., the cappuccino. In this blog I will explain everything about relating or composing transactions, for which I will also introduce the concept of transactor role.

Product Composition

Without going into the details of frothing the milk versus steaming the milk, or how to create latte art, the basic steps of making a cappuccino are:

1. Make an espresso;
2. Froth the milk; and
3. Add milk to espresso to make the cappuccino.

We can create a product breakdown structure to visualize the product composition. Note that we formulate the product kinds as completed events, as if the product has been created.

Now, if we want to make this a true business process, we need to add the serving of the cappuccino and a payment. Instead of adding this into the product breakdown structure of making a cappuccino, we add a transaction called ‘cappuccino completion’ that combines the previous breakdown with the new product kinds. This greatly enhances the reusability of the different components.

The level of detail in such a product breakdown is relatively arbitrary: it is up to the modeler what is shown and what is left out. Depending on the scope and objectives of the model or case at hand, a product kind can be defined at a high level (e.g., house is build) or at a very detailed level (e.g., screw is tightened).

Transactor Role

As shown before, every transaction involves two actors: an initiator (customer) and an executor (supplier). When transactions are composed, the executor of one transaction becomes the initiator of another transaction. In order to be able to show that, we will now ‘merge’ the symbol of a transaction kind with the symbol of an actor role (or area of responsibility, denoted by a box) into one symbol that represents both the transaction kind and its responsible (executor) role. Together this is known as transactor role. Note that the transaction symbol implies the complete transaction pattern, including all possible discourse and revocations acts.

Transaction Composition

As explained before, every transaction is aimed at one product. Or, vice versa, every product is created in a transaction. Turning a product breakdown structure into a tree of transaction kinds is as easy as replacing every product kind by a transactor role – the unit that represents both the transaction kind and its responsible actor role. Note that we replaced the product formulations by more active names of the transaction kinds that create the product.

In order to further clarify the focus of this model, two actor roles are greyed-out. Both grey-shaded roles are likely to be played by a person that does not work at the coffee corner, while the white-shaded actor roles are likely to be played by a person that does work at the coffee corner. Greying out actor roles is a way of defining the focus of the model.

The transaction tree can be read as follows. Somewhere in the process of completing a cappuccino, the cappuccino should be made, the cappuccino possibly needs to be served, and its needs to be paid for. It does not state yet when exactly, and/or under which conditions a sub transaction (every transaction that is not at the top of the tree) should be started. Those details can be added and detailed in some other views that I will discuss in a separate blog on DEMO model aspects.

Benefits of Composing Transactions

Composing transactions is a very natural process: in order to produce some product, you may need other (partial) products or (raw) materials, for which you have to initiate a (sub) transaction. This holds for both tangible as well as intangible products; e.g., a granted subsidy may depend on an elaborate content investigation as well as a financial investigation. Counter transactions such as payment for the delivered product can also be integrated into the process by means of composition.

Composing transactions can be done up to any level of detail desired. Moreover, it does not matter whether the executor is working at the organization(s) in focus, or a customer or a supplier. Composition thus makes it really easy to expand (or reduce) the model, while being consistent in the way the enterprise or chain thereof is modelled.

In a next blog I will show in detail the different models of DEMO to show the dependencies between (trees of) transactions.