Frydenlunds Allé 6
2950 Vedbęk, Denmark
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 traditional specification of a business process , ,  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. ). 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.
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.
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  and is illustrated in Fig. 3. The catalogue consists of eight major components.
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
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 , 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.
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.
 Hruby, P.: Framework for description UML Compatible Development
Processes, <<UML>>'99, Fort Collins, CO, October 1999.
 Designing Business Process-Based Software, white paper, Ensemble Systems, March 1999.
 Enterprise Application Modeling, A technical white paper, Proforma Corporation, 1998.
 Process Mentor Process Architecture and Meta Model, Object-Oriented Pty Ltd., February 1999.