In a previous blog, I introduced the four model aspects of a DEMO model: Cooperation, Process, Facts and Action. By abstracting from implementation details, organizational structures and ICT components, a DEMO model provides a stable view of the enterprise’s operation.
In this article we take a closer look at the Cooperation aspect, the highest-level conceptual representation of an enterprise. The Cooperation aspect focuses on the products an enterprise delivers, the actor roles responsible for creating those products, and the relationships between them.
Concepts
Formally, the Cooperation aspect shows the transactor roles (TAR) – consisting of a transaction kind (TK), its related product kind (PK) and its related responsible executing actor role (AR) – , other relevant (external and composite) transactor roles, initiation links between (trans)actor roles and transaction kinds – building the product tree -, (external) fact banks, and access links between actor roles and fact banks. The transaction kind is formulated as a noun + verb (gerund form). The product kind is formulated as some text with one or two variable(s), denoted between [], + ‘is’ + verb (past form). The executor role is formulated as noun + verb (root form) + ‘er’.
For example, in e-commerce, we have a transactor role TAR01 concerned about starting a membership. The transaction kind (TK01) is called ‘purchase completing’, the product (PK01) is called ‘[purchase] is completed’, and the responsible actor role (AR01) is called ‘purchase completer’. There is another transaction role (TAR02), consisting of TK02 ‘purchase paying’, resulting in PK02 ‘[purchase] is paid’, with responsible actor role AR02 ‘purchase payer’. We have one additional (external) actor role CTAR00 ‘customer’. CTAR01 can initiate TAR01 and TAR01 can initiate TAR02.
A fact bank represents a collection of facts relevant for the enterprise. Conceptually, it can be considered an information view on one or more transaction kinds, containing all facts created through the underlying transactions. Every transaction kind also represents a fact bank, containing all facts created in transaction of that transaction kind. Additionally, external fact banks may be defined, containing facts that are created outside the focus of the DEMO model, through transactions that may be unknown. As a result, such an external fact bank is modelled as an aggregate of multiple transaction kinds (MTK). An access link between an actor role and a fact bank indicates that the actor role needs some facts from the fact bank to perform its responsibilities.
In the example, there may an (external) fact bank MTK01 containing the products that are being sold, including current stock. Another example is client information (MTK02). Both are necessary to complete a purchase, but nor products nor customers are created through transactions of the kind mentioned above. At some point in time, one can always consider to ‘open up’ an external fact bank and detail the transaction kinds and actor roles inside of it. When modelling cooperation, it is often sufficient to show access to these facts of a certain type, without modelling the transaction kinds through which those facts can be created. Both CTAR00 and TAR01 require access to the ‘fact bank MTK01 ‘products’, and TAR01 needs access to MTK02 ‘customer information’.
Representations
The Cooperation aspect is expressed in a Transactor Product Table and a Coordination Structure Diagram. The first one is a textual representation, the second one is visual.
Transactor Product Table
The Transactor Product Table (TPT) provides a compact textual representation of the Cooperation aspect. It identifies the transactor roles in terms of a transaction kind, its related product kind and its related responsible executing actor role. As the DEMO model typically focusses on original production, the TPT only contains original transaction kinds – and not single coordination steps -, abstracted from implementation.
The TPT for the (simplified) e-commerce example is as follows.
|
Identification |
Transaction kind |
Product kind |
Executor role |
|
01 |
Purchase completing |
[purchase] is completed |
Purchase completer |
|
02 |
Purchase paying |
[purchase] is paid |
Purchase payer |
Coordination Structure Diagram
The Coordination Structure Diagram (CSD) visualises the dependencies between transactor roles within the enterprise. It depicts the transactor roles, external actor roles, external fact banks, and the relevant initiation and access links. A grey shade is used for everything outside the focus of this model; i.e., these parts won’t be further detailed in other aspects. Composite (trans)actor roles and multiple transaction kinds are outside the focus by default.
An initiation link from a(n) (trans)actor role A to a transactor role B, indicates that (trans)actor role A can initiate the transaction kind for which transactor role B is responsible. Collectively, these initiation relationships form the product structure of the enterprise.
An access link from a(n) (trans)actor role A to a (multiple) transaction kind C indicates that (trans)actor role A requires information from fact bank C in order to perform its work. Collectively, these access relationships provide a blueprint for information access control.
For the simplified e-commerce example, the CSD is as follows.
Why the Cooperation aspect matters
Many enterprise modelling approaches start by (in-depth) analysing processes, applications or departments. DEMO takes a different perspective: It starts with the essential transactions that create value for customers and stakeholders. As a DEMO model is independent of implementation with people and (ICT) means, it remains valid even when departments, job titles or software systems change.
Specifically, the Cooperation aspect answers questions such as:
- What products does the enterprise produce?
- Which actor roles are responsible for creating these products?
- How do products (or actor roles) depend on each other?
- What (internal or external) information is required to perform responsibilities?
In the fields of Business Process Modelling, Information and Data Modeling, and Business Rule Modelling, the DEMO Cooperation aspect is a truly unique view on the enterprise that provides a solid base for other aspects.
In the next articles I will detail the other DEMO model aspects: Process, Fact (information) and Action (business rules).
Comments (0)