In the previous installment of this series we explained the constructional view of modeling a business process in terms of business transactions, actors, and so on.  In this final installment, we explain how these concepts can be used for making the actual Business Model by taking a closer look at the Transaction Pattern Model that was introduced last time.

Modeling the Business Processes

In order to model the essence of the business process with DEMO one uses a number of aspect models.  The methodology offers a coherent and consistent set of different models to capture the core of the business system from different angles, each serving its own purposes in analysis (see Figure 5).  Together these models constitute the Business Model of a certain business system, showing the construction of this system (in other words, a 'white-box model').

Each of the model types in Figure 5 will be described in general, after which we will explain them using an example.

1. The Coordination Model

In practice, analyzing the business system will invariably start with the identification of the business transactions and the resulting facts.  These are preferably listed in what is called the Business Transaction List.  This list can be extended by including the actors. For each business transaction it is then indicated who is the 'initiator' and who is the 'executor.'  The Coordination Model is the basis of the business model, and it is used to show the actors and business transactions in a structured, graphical way.

This model gives an overview of the responsibilities of actors, as it indicates what relevant transaction types there are and by which actors they are executed or initiated.  Additionally, this model shows which fact- and rule-bases need to be inspected by every actor for acquiring the knowledge needed.  In the Coordination Model, the boundary of the system under study is also drawn.

2. The Process Model

The second graphical model is the Process Model.  This model shows the causal (initiating) and conditional (waiting) relationships between transaction types.  As a result one can see the structure of the business process in this model.  For each transaction type, it is indicated what other transactions need to be initiated in which phase.

For example, the model could show that the payment transaction is started during the execution phase of the order transaction.  It is also indicated in this model whether there are conditional relations between processes.  For example, the fact that a certain transaction needs to be accepted before another transaction can be requested.

3. The Fact Model

In the Fact Model the facts that were initially identified in the business transaction list are modeled in greater detail.  All constituent and attributive facts are described accurately.

Also, the derived facts that actors prefer to use are included and precisely defined in this model.  Put differently, one could say that the Fact Model specifies the "state spaces" of both the object world and the intersubject world.

4. The Action Model

The Action Rule Model (or, simply, Action Model) is a collection of behavior or action rules that apply to every step in the Transaction Pattern Model of every transaction type.  So these rules guide the actors in taking the objective and communicative actions to be performed in a certain business process.  This model is very well suited to start setting up workflow rules.

Note that the action rule list is still at the essential level and therefore does not show any informational and documentational tasks that the actors need to perform in order to effectuate their actions.  For example, we would not included in this model the detail that a certain letter needs to be sent to confirm acceptance of goods.  These detailed tasks could be added later on.

Rather than explaining all these models in theory we will give an example of the most important ones -- the Coordination Model and the Process Model -- hereafter.  The Fact Model and the Action model will be introduced in a follow-on article, where they become relevant in relation to defining business rules.

The Library Case

The goal of this section is to demonstrate how the different models can be used to capture the essence of a business process.  We take the simple situation of a public library as an example, as described in the following narrative.

We now illustrate the four modeling steps using this library case.

Step 1. Identify business transactions and resulting facts

Five transaction types can be identified from this description of the library services.  For example, there is a transaction in which new members are accepted, resulting in the fact that a certain person is now member of this library.  A second example of a transaction is the lending of a book.

The five transactions are listed in Table 1.  For each of these transactions, a precise and unambiguous specification of the resulting fact type is provided.  It is not only this identification of the essential transaction types but especially the formulation of their resulting fact types that is very important.

Table 1: Business Transactions List

Transaction Type	Resulting Fact Type
T1 Member-Registration	Membership M (Person P, date D) has started
T2 Member-Payment	Membership M (Person P, date D) is paid for
T3 Lending	Lending L (Copy C of Book B, date D, membership M) has started
T4 Returning	Lending L (Copy C of Book B, date D, membership M) has ended
T5 Fine-payment	The fine for lending L (Copy C of Book B, date D, membership M) is paid

Note that for reasons of proper analysis the conceptualization of the notions of 'membership' and 'lending' or 'loan' is crucial.  Administrations will typically include a reference to the business transactions.  In this case the lending and membership concepts are the key uniquely identifiable 'things' that are at the core of the 'business' of a library.

One can refer to the facts resulting from the transaction (in short) as "Lending L is effectuated" or (in more detail) by the precise and identifying facts that state the coming about of the result of this transaction.  A 'lending' is defined in more detail by its constituent facts, which will state that it "concerns the lending of a particular copy of a certain book by a particular membership on a certain day."

Later on, while doing the data analysis for the information systems, these facts will need to be described further by adding their attributive facts.  An example of an attributive fact of a lending is the amount of the (optional) fine.

Step 2. Determine actors and make Coordination Model

The next step is to identify the relevant actors and to determine their roles as 'initiator' and 'executor' of the transaction types.  When defining actors, it is modeling practice to abstract from existing persons and organizational structure.  Actor-roles are set as responsibilities or roles in relation to the business transaction, no more and no less.  More precisely, an elementary actor is defined for the executioner's role of every business transaction.

As a result, one gets a coordination structure of the business process that does not reflect the current organizational structure and staffing.  In this case the actors are, for example, the "Registrar" (shown as 'A1' in Figure 6), which is the responsibility and authority to commit to making new members (transaction T1).  It is this actor who also coordinates the handling of the payments of the membership (T2).  An elementary actor can only execute one transaction, while the same actor can initiate several new transactions in order to comply with this commitment.

Figure 6: Coordination Model of the Library

Once both the executor and the initiator have been defined for each transaction type, all business interaction relationships are determined.  These are drawn as exhibited in Figure 6.

• Transaction types are represented by a symbol consisting of a disk with a diamond behind it.  The disk represents the 'coordination world part' of the transaction; the diamond represents the 'object world part.'  Therefore, the disk can also be considered as a bank that contains the information on the coordination, and a diamond can be considered as a bank that contains the facts that are created as the result of successfully completed transactions.
• Boxes represent actors.  A white box represents an elementary actor, i.e., an actor that is executor of precisely one transaction type, and a gray box represents a composite actor.
• A transaction type is connected to its initiator and executor by means of lines.
• A small black disk at the end of a connecting line means that this actor is the initiator of the transaction type while a small white disk at the end means that this actor is the executor of the transaction.
• The system boundary is represented by a gray border line.

The diagram exhibits, for example, that actor A1 is the executor of transaction type T1 and that (some elementary actor in) the composite actor C1 is its initiator.  The converse holds for transaction type T2.

There are only two elementary actors in the kernel of the system under consideration:  A1 and A3.  The role of A1 is actually played by Lisa.  The role of A3 is partly played by Tim (complete executor role of T3 and initiator role in the O-phase of T4) and partly by Sanne (initiator role in the R-phase of T4 and complete initiator role of T5).

Step 3. Determine restrictions for actors

Figure 6 also exhibits the inspection and restriction relationships.  For example, the model shows that the lender (actor A3) has to have knowledge of the registrations (transactions of type T1).  This is represented by the dotted line from the symbol of T1 to the symbol of A3.

Furthermore, knowledge is needed from three external banks:  EB1, containing the admission rules, EB2, containing the library catalogue, and EB3, containing the lending rules (like, for example, the lending period).  Figure 6 also shows that the members (C2) are able to access the library catalogue (EB2) and the lending rules (EB3), and that persons (C1) have access to the admission rules (EB1).

The Coordination Model is now complete.  Note that, although all essential communication links are included, nothing is said about how they are implemented.

Step 4. Make Process Model

In the next modeling step, the Process Model is constructed.  This model shows how the transactions relate.  Figure 7 represents the Process Model of the library.  The Process Model contains only the 'intersubject world part' of the transaction types, putting focus on the coordination aspect.  In this way we get a view on the process, as the transactions will become nested.

Figure 7: Process Model of the Library

In this step, the transaction types are split up into the three O-E-R phases:  Order, Execution, and Result.  Arrows pointing at the O phase represent the initiation points of transactions.  For example, the upper part of Figure 7 exhibits the structure of the first business process of admitting new members.

This process consists of transaction types T1:member-registration and T2:member-payment.  T1 is initiated externally by a person who wants to become a member.  T2 is initiated during the execution phase of T1.  To represent this, the arrow that indicates the initiation of T2 starts from a small white disk on the edge of the Execution phase of T1.

The dotted lines with arrowheads represent conditional links.  For example, the dotted arrow, starting in the small black disk from T2 to T1/E indicates that T2 has to be completed before T1/E can be completed.  This reflects the fact that one only becomes a member after having paid the membership fee.

The lower part of Figure 7 exhibits the second process of lending and returning books, consisting of transaction types T3:lending, T4:returning, and T5:fine-payment.  This part contains a new symbol, namely the bar across the initiation arrow of T5.  This bar represents optionality.  Said another way, during the result phase of T4 a T5 may be initiated, but not necessarily.  In this way it is modeled that sometimes a fine has to be paid (T5) when returning a book (T4/R).  If there is a T5, then its successful completion is a condition for completing T4.  The decision whether T5 is executed is based on an action rule.

In Conclusion

According to DEMO, exploiting new technologies is always a matter of re-engineering the organization because (by definition) technologies have only to do with the realization of an organization's essence.  This essence is captured in the business model, of which we have seen two partial models.

However, the enabling potentials of modern networked ICT-systems do reach farther.  Therefore, the first step in transforming a 'normal' business system to an E-business system, is to investigate possibilities or opportunities to redesign the business processes, or even to redefine the business scope of the organization itself.

• Redefining the business of the library would mean adding and/or deleting interface transaction types, i.e., transaction types for which the initiator is in the environment and the executor is in the kernel of the system, or vice versa.  In our Library case, for example, instead of books one might also start lending CDs or offering completely new services.

• Redesigning the business processes of the library would entail that, in the Process Model (Figure 7), changes are brought about concerning the conditional relationships and/or causal relationships, for example, deleting the condition that paying the fine (T5) must be completed before returning a book (T4) can be completed, or starting the return of a book (T4) during the Order phase of lending (T3/)) instead of during the Execution phase (T3/E).

In a later article we will address the issue of aligning business and ICT from the perspective of the information systems model related to the business model.  Fully understanding this relationship allows for bi-directional optimization -- creating the best possible information systems for a business and, the other way around, exploiting existing systems to the best with the current business model.

References

1. Dietz, J.L.G., Understanding and modeling business processes with DEMO, in: Proc. ER’99, Annual International Conference on Conceptual Modeling, Paris, November 1999.
2. Dietz, J.L.G., DEMO: towards a discipline of Organisation Engineering, European Journal of Operational Research, vol. 128/2, January 2001, North-Holland.
3. Van Reijswoud, V.E., J.B.F. Mulder, J.L.G. Dietz, Speech Act Based Business Process and Information Modeling with DEMO, Information Systems Journal, 1999.
4. Hay, D, Anderson Healy, K, et al, Guide Business Rules Project, Final Report, October 1997.
5. Mallens, P.J.M., Business Rules-based application development, Database Newsletter, volume 25 number 3 May/June 1997.
6. Herbst, H, Knolmayer, G, Petrinets as derived process representants in the BROCOM approach, Wirtschaftsinformatik 38, 1996 4.
7. Davenport, T.H., Process Innovation: Reengineering Work through Information Technology, Harvard Business School Press, Boston, 1993.
8. Hammer, M., Champy, C., Reengineering the Corporation: A Manifesto for Business Revolution, Brealy, London, 1993.
9. Searle, J.R., Speech Acts, an Essay in the Philosophy of Language, Cambridge University Press, Cambridge MA, 1969.
10. Habermas, J., Theorie des Kommunikatives Handelns, Erster Band, Suhrkamp Verlag, Frankfurt am Main, 1981.
11. Lind, M., G. Goldkuhl, Reconstruction of Different Business Processes: A Theory and Method Driven Analysis, in: Dignum, F., J.L.G. Dietz, Proceedings of the Second International Workshop on Communication Modeling, Computing Science Reports, Eindhoven University of Technology, 1997.
12. Medina-Mora, R., T. Winograd, R. Flores, F. Flores, The Action Workflow Approach to Workflow Management Technology, Proc. 4th Int. Conf. on CSCW, ACM, New York, 1992.
13. Stamper, R.K., Applied Semiotics, in: Proc. of the ICL/University of New Castle Seminar ‘Information’, New castle, 1993.
14. Mintzberg, Structures in Fives: Designing effective organizations, Prentice Hall International, London, 1983.
15. Winograd, T. A Language/Action Perspective on the Design of Cooperative Work, in Computer supported Cooperative Work: A book of Readings. Irene Greif editor, Morgan Kaufman Publishers Inc., San Mateo, California 1988, pages 623 -653.

For more information the reader is referred to the website www.demo.tudelft.nl

# # #