Object-Oriented Architecture of Business Process Catalogue

Extended abstract, version 15 September 1999

Pavel Hruby
Navision Software
Frydenlunds Allé 6
2950 Vedbæk, Denmark
E-mail: ph@navision.com
Tel.: +45 45 65 50 00
Fax: +45 45 65 50 01

Abstract. Many contemporary business process models are focused on a description of business activities. Business processes are seen as activities that can be decomposed into subactivities and then again decomposed into tasks and subtasks. This approach is similar to structured programming, where programs consist of procedures that are decomposed into subprocedures and sub-subprocedures until the atomic level of programming instructions is reached. In contrast to this approach, this position paper suggests a different, object-oriented approach for business process modeling that focuses on a description of work results rather than activities and refinement rather than decomposition. In this approach, business products and services are seen as objects with various responsibilities, methods and attributes. Tasks are modeled as object methods and business activities as collaborations between the objects. This object-oriented approach can deal with the complexity of business processes in a better way than approach focused on the decomposition of activities.

The Problem

The traditional specification of a business process [2], [3], [4] is typically illustrated with a graph of tasks, activities and business products. Tasks are small behavioral units that usually create or modify a business product. Examples of tasks are "approve customer order", "update customer record" and "select item for shipping". Activities are units that are larger than task units. Activities typically consist of several tasks and often affect several business products. Examples of activities are "order management", "production planning" and "shipping". Business products are final or intermediate products delivered by business processes, for example, a "customer order", "customer record", and "product item". In this article, the terms "product" and "service" are used interchangeably and are used to mean a final or intermediate result of a business process. The business product or service is typically an information, which has a value to a business user and which is created or provided by a business process. We call this information "deliverable" if it is represented physically.

Fig.1 Traditional specification of a business process (After ref. [4]). It can be compared with the object-oriented specification illustrated in Fig.3

In general, the traditional specification of a business process cannot cover all the possible combinations of activities, tasks and business products without becoming overly complex. This paper will show that in the specification of business processes, the object-oriented approach deals with complexity of the business process better than the traditional approach illustrated in Fig. 1. This is similar to experience from within software development, where the object-oriented approach can deal with the complexity of large software solutions better than the traditional structured approach.

Basic Features of the Object-Oriented Business Process Catalogue

Business products and services (final or intermediary results of business activities) are considered objects with various methods and attributes. Business processes are represented as collaborations between the objects and actors. This section explains this idea in more detail.

Business products and services, seen as objects, have various properties and attributes such as purpose, owner, representation and relationships to other products and services. Different kinds of products or services have various attributes, but in common they should at least have the attributes name and state.

Business products and services, seen as objects, have various methods. Typically they have constructors, which are tasks that create a business product or provide a service, and quality-assurance methods such as various reviewing tasks, verification and approval.

Fig.2 Example of a business service type in the UML notation

Modularity and encapsulation of the business process catalogue are at the level of business products and services. Fig.2 shows an example of a business product "meal" which encapsulates attributes such as cost and cook time and tasks such as cook, serve, get consumer feedback and eat. The allowable order of the tasks is specified as a state machine.

In the traditional way, the same business service would probably be specified as "prepare meal", with the focus on the sequence of the tasks. A focus on the result of the service, as stressed in this paper, allows for specifying the purpose, attributes and tasks related to the service precisely, without it being necessary to describe a large number of allowable task sequences of "prepare meal". As a result of this, the traditional specification focuses only on the main success scenario, and often omits the quality assurance of the products and services. The object-oriented approach is precise and simpler, because the focus on the result of the service allows for a more abstract specification.

Architecture of the Business Process Catalogue

As described in the previous section, the first class citizens of the object-oriented catalogue of business processes are the final or intermediary products and services that an organization provides. The structure of the catalogue is based on the pattern for structuring UML design artifacts [1] and is illustrated in Fig. 3. The catalogue consists of eight major components.

• The product relationships specify static relationships between business products, services and business partners. Business products, services and partners can depend on each other, contain each other, inherit from each other or just refer to each other. Static relationships between products and services can be represented by UML static structure diagrams.
• The product interactions specify examples (instances) of business scenarios in terms of interactions between business products, services and business partners. The interactions between business products, services and partners can be represented by UML sequence diagrams or UML collaboration diagrams.
• The business product, described in terms of the purpose, responsibilities, properties and attributes, as well as in terms of the tasks related to the product, service or business partner.
• The product lifecycles specify the states of business products, services and business partners and the events that affect the state, such as creation, completion and approval. In particular, the lifecycle specifies the allowable order of the tasks performed on the product and service. The lifecycles can be represented by UML statecharts or activity diagrams.
• The product collaborations specify business process types in terms of their goals and purposes, preconditions, postconditions and attributes of business products, services and business partners that are accessed, or modified, by the business process. The collaboration types correspond to the concept of activity illustrated in Fig 1.
• The product collaboration relationships specify how business processes are related to each other and which business products, services and business partners can collaborate. This component specifies static relationships between business process types and business products and services. The relationships between collaborations can be represented by a UML static structure diagram.
• The product collaboration interactions specify typical sequences of business process instances. This component describes a business process instance consisting of other business process instances. The interactions between collaborations can be represented by UML sequence diagrams, or UML collaboration diagrams in which classifier roles are collaboration roles.
• The product collaboration lifecycle specifies the allowable order of tasks and events within the scope of the business process. Instances of business processes, specified in the component "business product interactions ", must conform to the collaboration lifecycle. The collaboration lifecycles can be represented by UML statecharts or activity diagrams.

Fig.3 Object-oriented architecture of a business process catalogue. The term "product" is used to mean both the business product, service and business partner

Features of the Object-Oriented Architecture

The business process catalogue described in this position paper is actually a catalogue of final or intermediary products and services that the business organization provides. Products and services are units of modularity in the catalogue. Object-orientation allows for encapsulation of the tasks inside the product and service types.

In the object-oriented model business processes cannot exist on their own. Business processes must be related to a business product, service or business partner. In the UML terminology we might say that business processes must be related to a classifier. This is an important fact that allows for maintaining a structure and relationships of the business processes. Because product and service descriptions are easy to structure in a succinct and consistent way [1], it is straightforward to find locations for business processes, activities and tasks simply by specifying their result or by finding a product they can relate to.

The fact that the model focuses on products makes it fundamentally different from the traditional approach that focuses on activities and tasks. A focus on products has several advantages over a focus on activities: it is usually easier to ensure the quality of a product than the quality of an activity. The object-oriented model allows for a distinction between the information itself and its representation. This allows for an alternative representation of products and services in specific situations. For example, the notation of software design products is often UML, but not always. It depends on who the intended reader is.

The focus on products allows for continuous improvement of the business processes. Users of the catalogue can attach their comments and suggestions regarding the business processes to the product or service specification. From time to time the owner of the product or service reviews the comments and updates the product specification.

Summary

This paper discussed the object-oriented architecture for the business process catalogue focused on business products and services. The business products and services are modeled as objects with constructors and quality-assurance methods, along with a number of specific attributes. The object-oriented specification of business processes is simpler and more consistent than traditional specification based on activities and tasks.

References