Business Process Decomposition and Service Identification Using Communication Patterns
Gerke Geurts and Adrie Geelhoed
Summary: Discusses communication patterns and their role in defining business processes and services. Such patterns afford decomposition of business processes into business, informational, and infrastructural services and the definition of their dependencies, thus providing a solid basis for enterprise information and application architecture. (14 printed pages)
The Business Transaction Pattern
Business Processes and Roles
Work Items and Action Rules
Three Layers of Services
Organizations use information and communication technology (ICT) as a means to reach their objectives. Paradoxically, many organizations find that yesterday's business ICT solutions hinder them in reaching today's objectives. An organization might be able to modify, wrap or replace existing ICT solutions to meet today's requirements, but how can it avoid today's solutions once again becoming tomorrow's problems?
Many business ICT solutions tend to lack flexibility to deal with changing business requirements and technology. Business requirements change as organizations adjust their strategies, business processes and internal structures to deal with changes in their environment (for example because of competition or legislation) or because they choose to merge or outsource activities. New technologies are introduced to obtain and maintain competitive advantage or because older technologies become too cumbersome and expensive to support.
A main reason for the lack of sufficient flexibility in business ICT solutions is the failure to consider long-term dynamics of business and technology during solution development. Should enterprise fortune telling therefore become a valued discipline within development projects? Not necessarily. To build ICT solutions that provide long-lasting support for organizations, it is essential to have models that help us to understand the structure and dynamics of the organizations we are trying to support.
Many of the today's organization and business modelling approaches are based on 'best practices' but to a certain extent remain a black art. What is often missing is a stable theoretical foundation such as the DEMO (Dynamic Essential Modelling of Organizations) framework [Dietz 2002]. By looking at organizations from a communication perspective, DEMO recognises reoccurring communication patterns between people and proceeds to describe how these patterns combine to form business processes.
DEMO provides business analysts and ICT solution architects with tools to decompose the business processes into elementary business transactions. Each business transaction identifies a business role that operates as a miniature supply chain providing a well-defined service to other business roles. Thus when providing automated support to business processes, it makes sense to decompose business process logic according to the same patterns that occur in a purely human world. Therefore, the DEMO approach can be used to identify process-oriented business services in service-oriented and component-based ICT solution architectures.
In this article we will first discuss on how organizations are made up of cooperating people who use communication to align their actions. By studying how people use communication to align their actions, we will encounter the business transaction communication pattern. We will then describe how business transactions are composed to form business processes and enable the identification of business roles. Each business role provides a well-defined service for other business roles within or outside of the organization. By studying how business roles exchange and remember organization we will encounter organizational roles that provide informational and infrastructural services. This will result in a technology-independent information architecture that consists of business, informational and infrastructural services and describes their dependencies. We will conclude this article with some remarks regarding the realisation of services using human resources and/or technology.
An organization is a group of people who cooperate to achieve common objectives. In all but the simplest organizations no single person is able to perform all the work that must be done to achieve the common goals, so members specialize themselves and must cooperate for the organization to be effective. To improve cooperation, organizations tend to formalize the roles that members play within the organization and to agree upon common procedures to coordinate the work performed by different roles.
A business process is an ordered execution of activities by people playing organizational roles in order to produce goods or provide services that has add value in the organization's environment or to the organization itself. Each activity on its own can be regarded as a decomposable process, and as a sub-process of the containing process [Eriksson and Penker 2000:71]. For example, a sales process may contain a delivery activity that contains nested activities for the selection of a transport provider and the transport itself.
A person may play one or more roles within an organization. Each role represents the elementary authority and responsibility a person must have in order to perform a particular production act. In practice, roles do not usually correspond directly with organizational functions. Often organizational functions map to multiple roles and roles may be played by various organizational functions. For example, 'secretary' and 'claim handler' may be organizational functions within a social service. Both the secretary and the claim handler are allowed to refuse incomplete benefit requests, but only the claim handler is allowed to grant benefits to claimants. So both organizational functions can play the 'claim admission' role, but only one organizational function can play the 'claim granting' role.
The roles participating in a business process perform two types of acts: production acts and coordination acts [Dietz 2002]. Production acts contribute to the realisation of goods and/or services for the environment of an organization. The result of a production act can be material or immaterial. The manufacturing, storage and transport of goods are examples of material production acts. A verdict by a judge or a decision to grant a benefit claim are examples of immaterial products.
Different roles must cooperate when they are dependent on goods or services that are produced by other roles within or outside the organization. By performing coordination acts people enter into and honour commitments towards each other regarding the execution of certain production acts [Dietz 2002]. An example of a commitment is an account manager promising to extend a credit limit when requested to do so by a client.
A successful production act causes a change in the 'production world' (the creation of a good or service), which is recorded as a production fact. Similarly, a successful coordination act causes a change in the 'coordination world' (the creation or compliance with a commitment), which is recorded as a coordination fact. Examples of production facts are 'John's club membership has started to exist' and 'product P has been transported to location L'. Example of coordination facts are 'John has requested Ferdinand to start John's club membership' or 'supplier representative S has promised customer representative C to transport product P to location L'. This principle is shown in Figure 1.
Figure 1. Coordination and production worlds
A coordination act is performed by one role (the performer) and directed to another role (the addressee). Because people are not able to read one another's minds, the performer must communicate with the addressee to share his thoughts.
To introduce some communication (and information) concepts we will use an example. A bank client wants his account manager to arrange a higher credit limit on his bank account. To communicate with his account manager, the client formulates his desire for a higher credit limit (mental state of speaker) in a message using a language that both he and the bank manager understand (common language). He then converts the message into perceivable signs by speaking out the message. Sound waves in the air (a communication channel) surrounding the client and the account manager transport the signs to the account manager. The account manager hears the signs and reconstructs the message. She subsequently interprets the message to determine its meaning (mental state of the hearer). She understands that her client wants to increase his credit limit, but as he has a private and a joint account she asks him which account is involved. The client indicates he wants to adjust the credit limit on his private account. Once she understands completely what her client wants her to do, she checks his credit rating and then promises him she will perform the requested action. Both parties understand that she has committed herself to increasing the credit limit on his private account and that she is expected to comply with her commitment (common social culture).
The example illustrates that communication takes place by the exchanging of messages. However, the example also shows that communication is more than the mere exchange of information. When communicating, people try to influence each other's behaviour. By everything they say, they do something [Reijswoud and Dietz 1999:5], i.e. they perform communicative acts. This principle is the main tenet of the Language/Action Perspective (LAP) [Austin 1962; Habermas 1981; Searle 1969], a methodology that considers communication from an action perspective.
Messages or communicative acts have a form (syntax) and a meaning (content in the form, i.e. information). The form of a message consists of the language the message is expressed in and the substance (e.g. sound waves, electric charges, light pulses) that carries the message [Dietz and Mallens 2001]. The meaning of a message consists of an intention, a fact and a time-for-completion [Reijswoud and Dietz 1999:13]. A fact specifies a certain action or state of affairs (for example, the credit limit of client account 1-345 is €2000). The intention of a message reflects how a message is intended to be taken by the receiver (e.g. request, promise). Depending on their intention, messages can be grouped in five families:
- Assertives commit the speaker to something being the case (for example stating);
- Directives try to get the hearer to do something expressed in the message (for example asking, requesting and commanding);
- Commissives commit the speaker to one or more actions in the future (for example promising);
- Declaratives bring about a new state of affairs by merely declaring it (for example declaring);
- Expressives express the attitudes and/or feelings of the speaker about a state of affairs (for example apologising).
The time-for-completion of a message specifies how long the combination of the fact and the intention are valid. In day-to-day conversation the time-for-completion tends to be implicit and a default value of 'now' or 'as soon as possible' is assumed. Figure 2 shows the form and content of a sample message.
Figure 2. Message form and content
A communication process is successful when mutual understanding is reached, i.e. when the mental state of the speaker and the generated mental state in the hearer correspond [Reijswoud and Dietz 1999:14]. To achieve mutual understanding the speaker and the hearer may ask each other for clarification. Communication is only complete when the hearer confirms he has understood the speaker.
A conversation is a sequence of communicative acts between two people with a particular goal [Dietz and Mallens 2001]. Technically, conversations consist of communicative acts that share the same fact and time-for-completion (see Table 1) [Reijswoud and Dietz 1999:20]. Within business processes two kinds of conversations are relevant. Performative conversations aim at letting other people do something. Informative conversations aim at the sharing of existing knowledge. The main difference between performative and informative conversations is that performative conversations are about the creation of new (production) facts, whereas informative conversations are about the distribution of knowledge. Examples of informative and performative conversations are shown in Table 1.
Table 1. Informative and performative conversation examples
|Informative conversation (natural language):||Performative conversation (natural language):|
|Harry: what is the capital of the Netherlands?
|Person W: The house will be clean when I come back home tonight, won't it?
Sally H: Off course it will be.
|Informative conversation (communicative acts):||Performative conversation (communicative acts):|
|Harry: asks: Sally:|
What is the capital of the Netherlands?
Sally: States: Harry: Amsterdam.
|Person W: requests: Person H:|
The house is clean tonight.
A coordination act is a communicative act directed from the performer of the coordination act to an addressee. As a communication act consists of an intention, a fact and a time-for-completion, coordination acts can be fully specified as follows [Dietz 2002]:
<performer>: <intention>: <addressee>: <fact>: <time-for-completion>
A coordination act is always about a production act, or more precisely about the production fact, whose creation marks successful completion of the production act. The fact in the specification of a coordination act therefore is a production fact.
Examples of concrete coordination acts are:
Mark: request: Esther: credit limit of account 1-345 is €2000:tomorrow Greg: promise: Harvey: Greg's article for journal #1 is written:13/10/2003
The successful completion of a coordination act is recorded as a coordination fact, which can be specified in the same way as the coordination act. For the performer of a coordination act, the coordination fact represents his/her expectation that the addressee will perform certain actions. From the perspective of the addressee the coordination fact is a 'business event', an event within the organization or its environment that triggers the organization to perform some action [Eriksson and Penker 2000:74]. An example of coordination (f)acts and business events is shown in Figure 3.
Figure 3. Structure of coordination (f)acts or business events
When studying conversations between people who are trying to coordinate their actions, the communicative acts that make up the conversation appear to follow the same conversation pattern, regardless of the business context. Dietz and Mallens  describe this pattern as follows:
First of all, one agrees upon what is to be achieved. Next the execution takes place in the production 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 block of a business process.
The three phases of the business transaction pattern are shown in Figure 4.
Figure 4. Activity diagram for business transaction pattern
A business transaction involves two roles; a customer or initiator role starts the business transaction, and a supplier or executor role actually performs the intended action. The first phase of a business transaction, the order phase, is a performative conversation that starts with a request from the customer to perform a particular action and ends with a promise by the supplier. During the execution phase the supplier performs the requested action. The transaction is concluded with a performative conversation in the result phase, which starts with a statement from the supplier that the requested action has been performed and finishes when the customer accepts that the action actually has been performed as originally agreed.
The amount of interaction (negotiation) that takes place between customers and suppliers in the order and result phases can vary strongly. In practice there are instances where certain steps are taken implicitly and no communication occurs at all. For example, the expiry of the period in which a customer can return bought products to a shop can be regarded as the implicit acceptance by the customer that the shop has fulfilled its obligations. In other situations long negotiations may take place before suppliers promise certain actions or customers accept the outcome of a production action. The ICT industry (unfortunately) provides plenty of examples in this respect. Reijswoud and Dietz [1999:98-108] describe the business transaction pattern in greater detail.
In each of the three phases in a business transaction, new business transactions can be initiated whose outcomes are required to continue with the original transaction. In this way it is possible to create arbitrary complex structures of nested and chained business transactions. Dietz  defines a business process as a structure of causally interconnected transactions for delivering a particular final product to the environment. In other words, a business process starts with a top-level business transaction which is initiated by a role in the environment of the organization and which may include other business transactions. These child transactions produce intermediate goods or services (production facts) that are required to successfully complete the parent transaction.
Figure 5. Example business process [Dietz 2002]
Figure 5 shows an example business process for the registration of library members. The business process consists of two business transactions. The 'member registration' business transaction is initiated by a person who wants to become a library member and executed by employees of the library who are authorised to register new members, i.e. they are allowed to play the 'member registration' role. A person must pay before being registered as member. For this reason the 'member registration' role initiates a second business transaction to obtain payment of the membership fee. The executor of the 'membership payment' transaction is the 'membership payment' role.
Though the 'membership payment' role usually is played by the same person who initiates the membership registration transaction, this is not necessarily the case, e.g. an altruistic friend or relative might pay the fee. This particular example illustrates an important principle: every business transaction has by definition one corresponding business role, which represents the elementary amount of authority a person must have to be an executor of the transaction. Dietz  explores the subject of authorisation in greater detail.
Each business role that is responsible for the execution of a particular business transaction operates as an elementary supply chain. Actors in a particular business role can act as supplier in one business transaction and as a consumer in an arbitrary number of subordinate business transactions (see Figure 6). Every business role provides an elementary and well-defined business service and may consume one or more other elementary business services offered by other business roles.
Figure 6. Business roles
Up until this point in our analysis of how organizations achieve their objectives, we have focused on how organization members 'talk' to each other to align their acts. In the following sections we will concentrate on what people do between coordination actions.
An organization springs to life when a business event occurs—that is, when a coordination fact is created. The coordination fact is created within a particular business transaction instance and signals there is work to be done by one of the roles that participate in the transaction, unless the coordination fact signals the end of the business transaction instance (for example a business transaction has reached the 'accepted' or 'stopped' state).
Every business role has a work item list that contains prioritised entries for all coordination facts that the role must respond to. Whether a coordination fact results in a work item for the initiator or the executor of a business transaction depends on the intention of a coordination fact. For example, a request results in a work item for the executor, whereas a promise creates a work item for the initiator.
An action rule (shown in Table 2) specifies the actions that must be performed by a certain business role in response to a particular coordination fact [Dietz 2002; Reijswoud and Dietz 1999:117-128]. Though action rules are procedures for business roles, these roles always remain responsible for taking well-considered and socially acceptable decisions, even if that means deviating from the procedures! This is a fundamental reason why it is not possible to fully automate the execution of action rules. When automating action rules, the people who are responsible for the execution of these rules must be able to intervene in and overrule the automated procedures.
Table 2. Examples of action rules [Dietz 2002]
|Business Role||Work Item||Action Rule|
|Membership Registration||on requested MembershipRegistation(M)||with person P is member of new membership M
if Age(P) > minimal age for membership and number of members < maximum number
|Membership Registration||on promised MembershipRegistation(M)||Request MembershipPayment(M)
with fee(M) is remaining_fee(M)
|Membership Registration||on accepted MembershipRegistation(M)||if promised MembershipRegistration(M)
<decide to start membership M>
state membership M has started
The daily life of a person in a business role consists of selecting the work item with the highest priority from his/her work item list and performing the applicable action rule. The execution of an action rule always ends with the performance of one or more coordination acts to pass the buck on to the next role that must play its part in the business process. The coordination act may be preceded by one or more actions to retrieve or calculate facts and/or a production act. provides some examples of action rules written in pseudo code.
The participating roles in a business transaction must have knowledge about applicable business rules (restrictions), production facts and coordination facts in order to be able to act responsibly. The restriction that someone can only rent a video if he has paid all previously completed rentals is an example where knowledge of production facts is needed. Video store employees need knowledge of coordination facts (in this case unfinished video return transactions) to be able to comply with the restriction that a customer may not rent any videos if he/she still has any unreturned videos.
In many cases knowledge of external rules and facts is also required. Legislation and standards are examples of external rules on how acts are to be performed. In any stage of a business transaction external knowledge may be required. For example, during the assessment of a benefit request, a social service may require additional information about the income, housing situation, household and health of an applicant. As the actual facts that must be known about an applicant might depend strongly on his or her situation, the applicant only has to provide a limited amount of information in the benefit request. Additional information will be requested from the applicant and/or other organizations when necessary. Figure 7 shows business process and business knowledge concepts.
Figure 7. Business process and business knowledge concepts
We can view the actions that take place within a business process at three levels of abstraction: the business, informational and infrastructural level. So far we have focused on the business level. At this level we see business roles that are played by social actors; actors who are aware of the social implications of their actions. These actors are responsible for the coordination of production acts by entering into and complying with mutual commitments. They are also responsible for the execution of production acts.
Social actors use the services of rational actors to memorise and remember knowledge and to exchange messages with other actors. Rational actors can perform logical operations on knowledge, but have no awareness of the social context they operate in. They play roles at the informational level, as they are responsible for the gathering, remembering, providing and computing of knowledge. We can see what knowledge is remembered and distributed by these actors, but cannot see how the storage and transmission takes place. That is, we can see the meaning of documents and messages but cannot see their form.
Rational actors depend on the services of formal/physical actors to produce, distribute, store, copy and destroy data or documents that contain knowledge. These actors play infrastructural roles: they deal with data and documents but do not show any interest in their meaning.
The actors at the business, informational and infrastructural level provide three types of services, layered on top of each other. At the business level we find business transaction execution services that coordinate other business transaction execution services and informational services to produce a particular good or service. At the informational level we distinguish three categories of informational services: communication services enable the exchange of messages between business roles, computation services offer facilities to compute derived facts and information management services provide long-term memory of (production, coordination and external) facts and business rules. Informational services depend on infrastructural services for the storage, distribution and calculation of data. The dependencies between these roles are shown in Figure 8.
Figure 8. Business role support by informational and infrastructural roles
The realisation of services at all three levels of abstraction can vary from being fully manual to highly automated. Human beings are able to perform roles at all levels, whereas machines are very capable to perform infrastructural and informational tasks, but have absolutely no social awareness. It is for this reason that machines cannot carry the responsibility for performing actions in a socially acceptable manner. In the end there must always be a person who is responsible for the execution of business transactions.
A human actor who plays a certain business role can delegate parts of the execution of business transactions to a machine, but he/she will always remain responsible for the result and have to stand by to deal with exceptional situations. For example, an e-commerce web site may handle the majority of orders without any human intervention. However, a customer who does not receive his order will contact a sales person to resolve the problem.
By analyzing how and why communication takes place between cooperating persons, we have encountered the business transaction communication pattern. We have seen how instances of this pattern are chained together to form business processes. The understanding that business processes are composed of business transactions enables us to perform the reverse action; the decomposition of business processes into business transactions.
Each business transaction identifies one business role, which represents the elementary amount of authority and responsibility to execute the transaction. These business roles are the building blocks for authorisation policies within organizations.
Each business role can be viewed as an elementary supply chain and provides a well-defined service. By studying how these services are realized we have encountered the need for additional informational and infrastructural services to enable storage and exchange of information.
The decomposition of business processes into business, informational and infrastructural services and the definition of their dependencies provide a solid basis for enterprise information and application architecture. As technology has not played a role in the decomposition of business processes into services, the resulting services are technology-independent. The degree to which services are automated may vary strongly, but this has no influence on the information architecture.
When implementing a service, we would recommend hiding both the chosen implementation technology from other interacting services as well as the degree of automation within the service. This approach provides an organization with the flexibility to change the technology itself as well as the way it is applied in business process implementations.
We started this article with the question how to avoid today's solutions becoming tomorrow's headaches. Focusing on communication patterns that stay the same regardless of technology and business process changes certainly seems like a good place to start.
More information on DEMO can be found on the DEMO web site. The DEMO handbook [Reijswoud and Dietz 1999] provides detailed information on the theoretical background of DEMO and also describes a business modelling approach.
J L Austin, How to do things with words, Harvard University Press, Cambridge MA, 1962
J L G Dietz, The Atoms, Molecules and Fibers of Organizations, Data & Knowledge Engineering, 2003,
Dietz and Mallens 2001
J L G Dietz, P J M Mallens, An Integrated, Business-Oriented Perspective on Facts and Rules, data2knowledge newsletter, January-May 2001
Eriksson and Penker 2000
Business Modeling with UML: Business Patterns at Work. Wiley Computer Publishing, 2000
J Habermas, Theorie des Kommunikatives Handelns, Erster Band, Suhrkamp Verlag, Frankfurt am Main, 1981
Reijswoud and Dietz 1999
V E van Reijswoud, J L G Dietz, DEMO Modelling Handbook Volume 1, Delft University of Technology—Department of Information Systems, Version 2.0, May 1999
J R Searle, Speech Acts, an Essay in the Philosophy of Language, Cambridge University Press, Cambridge MA, 1969
About the Authors
Gerke Geurts is a technical architect within LogicaCMG. He has a keen interest in the many facets of software development in an enterprise setting. His waking hours are spent coaching and trying to stay ahead of clients, software developers and his children. Gerke can be reached at email@example.com.
Adrie Geelhoed is an enterprise architect working for LogicaCMG Financial Services and provides business-centric architecture and software development guidance to customers and consultants. Adrie can be reached at firstname.lastname@example.org.
This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit the Architecture Journal website.