In this article we continue with the second of a three-part series in which we explain our views on the alignment between business systems and information systems.  In the first part, we introduced DEMO, Dynamic Essential Modeling of Organizations [1,2,3].  DEMO is a (re)engineering and development methodology that offers concepts and modeling techniques for business processes.  DEMO is developed to give the information systems designer an appropriate view on the business process.  DEMO provides the modeling instruments for representing the essence of business processes.  In part 1, we identified three aspects of information and related those aspects to three perspectives on organization, as summarized in Figure 1.

In this installment, we focus on the essential perspective by introducing the modeling concepts for the business system and its processes.

A Constructional View on Business Systems

A business system implements the desired way of doing business.  The information system is a system in support of the overall business system.  Information and communication technology (ICT) is a technology that is applied to effectuate, or 'realize,' an organization in its communication and its handling of information, making it operational in these aspects.  ICT can be compared to other realization aspects such as the staffing with personnel or the process of logistics needed for the realization of the business process.

We should always keep in mind the fact that this role of information technology is merely supportive.  To whatever extent ICT may have pervaded an organization, it can never take over what the organization essentially is.  We call the essence of an organization its business system (or systems, if one likes).

In order to align the ICT systems with the business process, one has to understand the business process in its construction.  Looking at the business process as a black box is not sufficient.  A 'constructional' viewpoint of the business process is needed, as the information system is used to effectuate the business process in its precise working.

So, key questions are:  What is the 'working principle' of organizations?  How are business systems 'constructed' and what is their essence?  What is the difference between business systems and information systems?

In order to find answers to these questions, we adopt this basic understanding of an organization:

• An organization is a system of social individuals or subjects.

  People play the essential roles in the business system; it is their social interaction and communication that drives the business process.

• Every subject has the authority to perform particular objective actions and a corresponding responsibility to do that in an appropriate and accountable way.  (Moreover, a subject will only be assigned authority if he/she has the appropriate competence.)

  By performing objective actions, subjects change the state of what is called the object world (object in the sense of 'target' or 'goal').  In doing that, the actors bring about, or fulfill, the mission of the organization, like producing bicycles or life insurance policies.

  For example, an 'objective action' is mounting the saddle of a bicycle or paying the claim resulting from a certain insurance policy.

• For the coordination of their actions, the subjects enter into and comply with commitments towards each other.  In this way the objective acts of the actors are coordinated.

  Examples of commitments are that actor A has requested B to mount a saddle and that actor B has promised A to do so.  The creation of commitments can be viewed as changing the state of another world, which we call the intersubject world.  This is the world of agendas and tasks-lists.  The term 'intersubject' expresses that this world only exists between subjects.

In order to recognize this essence of the business process, it is interesting to reflect on breakdowns -- on situations where things get out of control -- where it is not clear who is to do what, where people do not take their responsibilities, and so on.  The customer will soon be calling, asking the one who picks up the phone what is going on.  Most often the key question will turn out to be "who has promised what to whom?"

Communication

Communication is the prime instrument of coordination in and between organizations.  A business conversation between persons in an organization is a sequence of communicative acts between two subjects with a particular goal.  Two kinds of conversations are distinguished.

• First of all, there are conversations that aim at letting people act or perform.  We call these performative conversations.  These are basically the conversations that bring about business transactions.  They correspond with the performa aspect of information we described last time.
• On the other hand, there are informative conversations in which existing knowledge is shared.  The core intentions of these conversations are the question and the answer.  They correspond with the informa aspect of information.

The main distinction between these two types of conversations is that performative conversations are concerned with establishing new, original facts in the object world, whereas informative conversations are concerned with distributing (existing) knowledge of a world.

From the perspective of the ICT engineer this is a critical difference.  The notion of facts as a formal way to capture the results from business transactions is central to DEMO.  With the creation of facts, one completes the mutual agreement between parties on the states achieved, for example, the fact stating that the goods are delivered.  These real-world facts, in combination with facts concerned with the coordination of actions, are the basis of the information stored by organizations. [see sidebar]

Business Process and Business Transactions

Winograd [15] stated that "Conversations for actions are the central coordinating structure for human organizations."  Customers, employees, and suppliers enter into business conversations that aim at committing the other party to perform an objective act, to do something.  When studying these interactions it appears that they occur in a particular conversational pattern, consisting of three phases.

First of all, one agrees upon what is to be achieved.  Next, the execution takes place in the object world, for example, the shipment of goods ordered.  The commitment still stands, however, until the result is accepted between the parties involved, meaning that there is a third phase.  It is this pattern that we call a 'business transaction' -- the elementary building block of a business process.

In modeling business processes, it is necessary to abstract from the particular individuals that perform actions and to concentrate on their roles in carrying through transactions.  Therefore we introduce the notion of actor.  An actor is a role of a subject.  One actor role may be fulfilled by one or more subjects, and a subject may fulfill one or more actor roles.

As was said earlier (but now applies to actors), actors perform actions in the object world and in the intersubject world.  By performing objective actions they contribute to the production of goods or services, by performing intersubjective actions they interact and, in doing so, coordinate their work.  This is illustrated in Figure 2.

This 'direct' way of coordination is not the only kind of coordination that exists in an organization.  For a thorough discussion of all distinct kinds of coordination, the reader is referred to [14].  For the scope of this paper, next to the 'direct' way we distinguish an 'indirect' way of coordination, which consists of inspecting and using information by actors when acting.

The Pattern of a Business Transaction

Let us now have a closer look at the pattern of a business transaction.  First of all, it is typical that a transaction is carried through by two actors.  The one who starts the transaction, and eventually accepts the results, is called the customer, or 'initiator.'  The other one, who actually performs the intended action, is called the supplier, or 'executor.'

The generic transaction pattern consists of three phases, which we will explain using a typical successful business transaction:

• The order phase, or O-phase.

  First there is the request of the initiator.  In reaction, the executor promises to live up to the request.  For example, you stand in a bar and order two beers; the waiter nods.

• The execution phase, or E-phase.

  Now the objective action is executed.  For example, the waiter fills the glasses and puts them in front of you.

• The result phase, or R-phase.

  The executor needs to state that the result intended is achieved.  Next, of course, the initiator needs to accept this and thus ends the commitment.  The new state is now formally agreed upon; the new fact has come about.  For example, the waiter points at the glasses, and you nod to confirm that this is what you had asked him to do.

The O-E-R pattern with its detailed states and transitions is depicted in Figure 3.  The transaction starts in a wait state, indicated with a '0.'  The initialization comes with the request made by the Initiator (I).  As a result we now come in state 1, which indicates that the objective action is requested.  As a reaction, the Executor (E) will normally promise to act -- a transition leading to the state "promised," state 2 in the intersubject world.  Next, transition takes place in the target world, where the executor carries through the action, leading to state 3.

When the Executor has stated the fulfillment of the request (state 4), the Initiator will accept the result, leading to state 5 (accepted).  This means that the two parties have agreed upon the change in the object world, both accepting the coming about of the new and original fact 'F.'

Note that in practice people tend to cut corners -- not every step described has to be made explicitly.  For example, one could have a mutual agreement that 'no message' means that the acceptance is automatic within a day.  The other way around, one transition might involve extensive communication.  There can, for example, be quite a lengthy conversation to detail out the request before it is understood and acceptable for the executor.

Also, an actor may activate itself -- that is, it may be the initiator as well as the executor of a transaction.  In this way, all repetitive and periodic actions are modeled.  Moreover, although the actual start of a transaction is the request-act by the initiator, the actual subject fulfilling that role may be influenced to a large extent by the executor.  A typical example of this situation is 'selling' by a sales person.  The sales person may seem to play the most active part in the selling process; however, it is the customer who starts the transaction by performing the request act.

During each of the phases of a transaction, new transactions may be initiated, the result of which is needed to proceed with the original one.  In this way, transactions are chained and embedded into arbitrarily large structures called business processes.

Restricted to Act

In order to act accountably, actors must have the appropriate knowledge upon which to base their decisions about to how to act.  More precisely, they need to take into account the current state of both the object world and the intersubject world and then live up to the rules set for them.

For example, one may "not be allowed to pay a claim when the customer has not paid the premium for the related policy" -- a restriction based on the state of the object world.  Or one may "not be allowed to pay a claim while still having a request for counter-expertise open" -- a restriction based on the state of the intersubject world.  Put differently, one could say that actors can be restricted in their actions by the states of both worlds.

These states are described as facts resulting from or related to the coordination of this transaction or of other transactions.  For acquiring the knowledge needed, and for possible business rules set externally, an actor might need to inspect external fact and rule bases as well.  For example, in mounting a bicycle saddle, the mechanic is restricted by the facts that the saddle and the bicycle have a particular form, by the scheduled mounting time, and so on.  These restrictions constitute the indirect way of coordinating actions.  According to DEMO, actors do have access to all information they need to use.  This is depicted in Figure 4.

The Complete Transaction Pattern

In this explanation, it has been taken for granted that the actors will respond successful to every step in the transaction.  This is what is called the success layer of the business transaction -- the pattern of the simplest route to success.

In practice, however, the transaction can show a more complex communication process.  Suppose the request is not immediately accepted because, for example, the executor does not want to supply under the conditions mentioned.  In this situation, the executor will not promise to comply but instead will challenge the request -- for example, to negotiate the terms.

Thus the transaction comes into a new layer, called the negotiation layer.  From this new state, the next move is to the initiator again, possibly leading to a new formulation of the request or to an abortion of the transaction.  In this way there are several routes from success layer to negotiation layer.  Think, for example, of the situation where the customer does not accept the stated result, and negotiation starts on the acceptance of the transaction.  Sometimes the discussion reaches a more fundamental level, where the underlying social framework comes to be subject to dispute.  Such conversations take place at the level of what is called the discourse layer.

Sometimes the cultural differences are too large to achieve a workable situation.  Only when the communicating social actors can agree to a set of norms and values can they establish successful business transactions.

In order to understand the conversational pattern within one particular business transaction in more detail and in order to understand possible exceptional situations arising, the specific Transaction Pattern Model of every transaction type has to be discussed.  In this model, all states and transitions that can typically occur in a business transaction are shown.  Not only does it show the success layer -- where everything goes as it is supposed to -- but it also includes the negotiation layer.  For example, 'what if' you don't want to accept the order from the customer as it is.  The Transaction Pattern Model is an underlying template that helps explain all of the other modeling techniques.  The concluding installment of this series will take a closer look at this Transaction Pattern 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

# # #