How Does an Enterprise Operate?
Part 7: Actor cycle

Earlier, I explained that the operation of an enterprise is comprised of two distinct kinds of activities – production and coordination – that can be further classified into four separate layers. Activities can be grouped into transactions that follow a specific (transaction) pattern, and can be composed to build a network of responsibilities. In this final blog on the enterprise operation, I will show how different activities build an actor’s to-do list and how these actors can deal with them.

Initiating a business process

Transactions at the top of a (product) tree – such tree is called a business process – can be initiated (requested) in two different ways: 1) by an external actor, and 2) by self-activation.

External

Examples of external actors include customer, (aspirant) member, etc. These are composite actor roles of which we don’t exactly know (or want to know) what they do and why they do things. The only thing we are interested in is that a person fulfilling that role can request some transaction.

Self-activation

If there is no external actor (role) found, than the transaction needs to be initiated through self-activation. This is an actor role where the initiator is the same as the executor. This is typically used for periodically recurring (management) transactions.

Operating cycle

New requests result in to-do items, commonly known as (the) agenda. The idea is that every actor constantly checks whether there are to-do items to deal with. The cycle starts by selecting one item of this list. The actor then fetches the applicable business rules (DEMO: action rules) and follows the procedure in which conditions are checked and the response is carried out. The latter typically results in a new to-do item, either for the actor itself – e.g., when a supplier promises to deliver some goods, the next to-do item is to actually deliver the goods (execute) – or for someone else – e.g., when the supplier declares delivery of goods, the next to-do item is for the customer to inspect and accept or reject the delivery. The response can even include requesting some other (sub)transaction – this creates a to-do item for some other actor as well, see, e.g., the cappuccino process.

Conclusion

This blog concludes the series on the enterprise operation. A next blog series will dive into how we can model an enterprise with the DEMO modelling language.