Pattern 2: Business process model **
AKA:

You have ESTABLISHed THE BUSINESS OBJECTIVES (1) and prioritized them in the first sessions of a joint requirements workshop.

You now need to understand the requirements and the business processes involved, both as they are now and after the site goes live. You realize that this is different from merely specifying the use cases for the site’s potential users, since many people involved (such as warehouse staff or credit card authorizers) may never even see the site. However, you must understand their needs and activities as well as those of users.

Therefore

Understand first the network of agents and commitments that make up the business. Specify the conversations that take place at an appropriate level of abstraction, so that they are stereotypes for actual stories. Get people to tell these stories. Ensure that you produce both ‘before’ and ‘after’ business process models. Eliminate conversations that do not correspond to business objectives (or discover the missed objective). Ensure every objective is supported by a conversation.

Now that you understand the before and after business models it is necessary to specify the site, so we must first ESTABLISH THE USE CASES (3) at the system boundary and divide them into groups to be delivered in individual TIMEBOXES (4).

This is another process pattern of sweeping generality but too often ignored by web developers.

The commonest misconception in computing is that understanding a client’s requirements is the same as specifying a system that will meet those requirements. On such a premise one can then blithely state that use case analysis is the only requirements modelling technique needed. Jackson (1998) pours scorn on this idea, arguing that use cases are useful for specifying systems but that they cannot describe requirements fully. Use cases connect actors, which represent users adopting rôles, to systems. Requirements, on the other hand, may be those of people and organizations that never get anywhere near the system boundary. A requirements document must be written in a language whose designations concern things in the world in which the system is embedded (including of course that system). Specifications need only describe the interfaces of the system and therefore depend on different designations. The specification describes the interface of phenomena shared between the world and the system; use cases may be used to express these. The requirements model is a description over these and other phenomena in the world; it depends on both the specification and the world. He also states that ‘the customer is usually interested in effects that are felt some distance from the machine’.

Ignoring the non-user interactions can lead to us missing important re-engineering opportunities. The model above depicts a rule-based order processing and auto-pricing system, whose aim was to take orders from customers electronically and price them automatically using various, often complex, pricing engines via the corporate object request broker (ORB). The problem was that some orders were too complex or too large to admit of automatic handling. These had to be looked at by a salesman who would of course have an interface with the ‘system’. So far, so good: a rule engine would screen ‘illegal’ or ‘handle manually’ orders. The salesman would then apply his various spreadsheet and other routines to such orders. But a further problem existed; some orders were so complicated as to be beyond the skills of the salesman, who did not have expertise in financial mathematics. For these orders, the salesman had to go across the office and talk to a specialist trader. She did have the requisite PhD in Financial Engineering. We also modelled non-use-case conversations (depicted in yellow) and, as a result, when our domain expert looked at the simulation we had built, she realized immediately that if we gave the trader a screen we could radically improve the workflow, and thereby customer service. Even this relatively minor excursion away from the system boundary thus had a big cash impact. In many web applications the importance of going beyond the boundary will be greater still.
Jackson’s argument implies that we need a specific technique for modelling business processes distinct from, but compatible with, use case models of specifications. The alternative is to fall back on a veritable ‘Russian doll’ of nested models described in terms of ‘business use cases’ (Jacobson et al., 1995): an approach that is not only clumsy but fails to address the above arguments.

Once the objectives are clearly stated with defined measures and priorities we can construct our first object model: an object model of the business area that we are dealing with. To do this we must understand what a business (process) actually is. Most vendors of business process modelling tools and techniques find it very difficult to answer the question: ‘what is a business process?' Typically, they might answer that a business is a set of processes connected by data flows, with timings for each process and (possibly) allocations of process responsibility to functional units. In other words, data flow diagrams enhanced with timings or perhaps UML (Unified Modelling Language) activity diagrams are all that is needed. What all these approaches have in common is that they lack an adequate theory of what a business process is. The theory behind this pattern is rooted in the science of Semiotics, and the work of Winograd and Flores (1986) on workflow systems. Rather than taking use cases as a starting point, we extract them from a process model.

Both requirements engineering and business process re-engineering must start with a model of the communications and contracts among the participants in the business and the other stakeholders, customers, suppliers and so on.
Consider some business or enterprise. It could be an entire small company, a division or department of a larger one or even a sole trader. A business process (or business area) is a network of communicating agents. Flores (1997) refers to this as a network of commitments. An agent is any entity in the world that can communicate; so it could represent a customer, regulator, employee, organizational unit, computer system or even a mechanical device of a certain type, such as a clock. Agents are autonomous and flexible. They respond to appropriate stimuli and they can be proactive and exhibit a social aspect; i.e. communicate. Typically agents exhibit some level of intelligence, human agents certainly so but mechanical agents insofar as they can initiate and respond to communication. This now begs the question of what it means for two agents to communicate. Agents need not be site users; i.e. actors. Agents – like actors – are to be thought of as adopting a rôle.
This ‘business’ must communicate with the outside world to exist at all and, if it does so, it must use some convention of signs and signals thereto. We can call these signals between agents semiotic acts. They are carried by some material substratum. They involve a number of semiotic levels from data flows up to implicit social relationships . For example, the substrate may consist of filled-in forms and the social context might be that one assumes that no practical jokes are to be played. If the substratum is verbal (or written) natural language then we can speak instead of speech acts or conversations. These are the speech acts of Austin (1962) and Searle (1969). Flores (1997) argues that business conversations have a constant recurrent structure based on only five primitive speech acts: assert, assess, declare, offer/promise and request.
Semiotic acts (or conversations as we wall call them from now on) can be represented by messages, which are directed from the initiator (source) of the communication to its recipient (target). By abus de langage we can identify semiotic acts, or conversations, with their representation as messages although strictly they are different; the same semiotic act may be represented by many different messages. This defines equivalence classes of messages and we can think of our actual message as a generic representative of its class; many contracts may express the same relationship so we choose one to represent its equivalence class.

A typical conversation is represented below where a typical external customer agent places an order with some business. This message includes the definition of the reply: {order accepted|out of stock|etc.}. We, quite legitimately, use the UML use case symbol to represent the conversation, but overload the UML actor symbol to represent agents.
Data flow in both directions along message links (via the request and hand-over stages discussed below). This is why we have chosen to terminate message links at the recipient end with a filled circle rather than an arrowhead. The line segment is directed from the initiator of the communication, not from the origin of the data.

We now begin to see that agents can be modelled as objects that pass messages to each other. Clearly agents can also be classified into different types as well.

We think of a business process as a network of related conversations between agents, represented by messages. It is inconceivable in most businesses that the message initiator does not wish to change the state of the world in some way as a result of the communication. This desired state of the world is the goal of the conversation and every conversation (or message) has a goal or post-condition, even if it is often unstated: the contract representing the conditions of satisfaction of the conversation.
A goal is achieved by the performance of a task. The innovation here is twofold. The tasks we perform can often be reduced to a few stereotypes: typical tasks that act as pattern matching templates against which real tasks can be evaluated and from which real tasks (or use cases) can be generated. This prevents an explosion in the number of use cases.

In business, only serious, goal-oriented conversations are relevant and therefore we can argue that each conversation has a sixfold structure as follows:

1. A triggering event: a world event that triggers the interaction.
2. A goal: a world state desired by the initiator of the conversation.
3. An offer or request, which contains the data necessary for the recipient to evaluate the offer or request.
4. A negotiation, whereby the recipient determines whether the goals are shared and the conditions of acceptance, leading to either a contract being agreed or the offer rejected. The contract formalizes the goal and provides formal conditions for knowing when the goal has been achieved satisfactorily.
5. A task that must be performed by the recipient of a request to achieve the goal and satisfy the contract. This is what is normally thought of as a use case when one of the agents is an actor.
6. A handover of the product of the task and any associated data, which checks that the conditions of satisfaction of the goals have been met.

This structure accords generally with that of a conversation for action in the terminology of Winograd and Flores (Flores, 1997; Winograd and Flores, 1986). Note also that there is a symmetry of offers and requests, so that we can replace every offer with an equivalent request by swapping the initiator with the recipient. Flores presents the theory in terms of a customer (our initiator) and a performer (our recipient) who executes the primitive speech acts – shown in italics in what follows. The customer assesses her concerns and asserts a request to the performer (dually the performer makes an offer). A process of negotiation then ensues, aimed at defining a contract that can be promised by the performer and accepted by the customer. This, and other stages in the conversation, may involve recursion whereby subsidiary conversations are engaged in. At the end of negotiation the contract defines the conditions of customer satisfaction, and then some task must be executed to fulfil their promise. Finally, the results of this work are declared complete and handed over to the customer who should declare satisfaction.

Consider the concrete example of buying a house. An initiator might say ‘would you like to buy my house?’ and the recipient would need to know, and would negotiate on, the price. This negotiation could well involve (recursively) subsidiary conversations between the recipient and a mortgage provider and a building surveyor. If everything is agreed then a contract will be agreed and signed (literally in this case). Now there is work to do; in England it is called conveyancing. The work involves searching local government records and land registry documents along with many other – all fairly straightforward – tasks. So this is the place where we might rely on a standard task script, as exemplified for example by the words (or flowcharts) in a book on conveyancing. Finally, when this task completes satisfactorily we can hand over the keys and the contract is said to be completed.

Of course, in business process re-engineering, we are eager to capture not just the messages that cross the business boundary, such as order placement, but to model the communications among our customers, suppliers, competitors, etc. This provides the opportunity to offer new services to these players, perhaps taking over their internal operations – for a fee of course.

Having analysed the business process in terms of conversations, we now focus on the task performance segment of the conversation: the use case if actors are involved. Before doing so let us remind ourselves of the model sequence. We started with a mission grid leading to several processes. Each process has several objectives. Also, there is now a network of conversations (messages). We should now ask two critically important questions:

• Does every message support the achievement of at least one objective?
• Is every objective supported by at least one message?

If the answer to either question is ‘no’, then the model must be amended. Either we have missed some conversations or we are modelling conversations that do not contribute to the achievement of any stated business objective. Of course, it is possible that we have missed an important objective and, in that case, the users should be consulted to see if the statement of objectives needs to be modified. If not, we have a clear re-engineering opportunity: just stop doing the work that supports no objective.

Known uses
This technique has been used successfully on hundreds of projects known to us around the world over ten years or so. About ten of these were web design projects.

UML provides another notation for business process modelling: the activity diagram. Our agent conversation diagrams offer a convenient alternative to activity diagrams which makes all implementation assumptions very explicit and, more importantly, in a way more readily understandable by users; the activity notation is quite hard to remember, understand and explain. Of course, there may be occasions when activity diagrams are helpful. Martin and Odell (1998) give the following criteria for deciding whether or not to use this kind of representation. Consider using activity charts if:

• an object has complex, significant state (use state charts);
• there is complex interaction between a few objects which trigger state changes in each other – as often found in real-time control systems;
• object behaviour is event driven and single threaded and objects have only one state variable (note that business processes are notoriously multi-threaded);
• the user culture supports their use – as in the telecomms sector.

Avoid them if:

• there are several threads (as in a typical business process);
• there is complex interaction between large numbers of objects;
• objects have several significant state variables.

Browse the language	What is Wu?	Look at an example pattern sequence	Structure of the patterns
Comment on Wu	Contributors	Return to TriReme home page	Links to related sites