To capture the complexity in business process management, different abstrac- tion concepts are introduced. A traditional abstraction concept in computer science is the separation of modelling levels, from instance level to model level to metamodel level, denoted by horizontal abstraction. Horizontal abstraction concepts in business process management are discussed in Section 3.2.1.
Even when using horizontal abstraction, separate subdomains need to be investigated. In order to follow the divide-and-conquer approach, these subdo- mains need to be represented separately. This abstraction mechanism is called vertical abstraction, and is discussed in Section 3.2.2.
Aggregation can also be used to cope with complexity, motivating another type of abstraction. At a higher level of abstraction, multiple elements of a lower level of abstraction can be grouped and represented by a single artefact.
For example, a set of functional activities of small granularity can contribute to a particular business function at a higher level of granularity: a coarse-grained business function “order management” might aggregate many smaller-grained activities, like receiving an incoming order, checking the inventory, and con- firming the order. This type of abstraction is called aggregation abstraction, because the coarse-grained business function aggregates activities of smaller granularity.
Aggregation abstraction is different from horizontal abstraction, because all activities (the small-grained and the coarse-grained) are at one horizontal level of abstraction, e.g., the instance level. Aggregation abstraction is primar- ily used in the functional subdomain, where functions of smaller granularity are combined to create functions of larger granularity.
3.2.1 Horizontal Abstraction
Along the lines of the levels of abstraction identified by the Object Manage- ment Group, the metamodel level, the model level, and the instance level play important roles in the design and analysis of complex systems in general and software systems in particular. It is instructive to explain these levels in a bottom-up order, starting with the instance level.
The instance level reflects the concrete entities that are involved in business processes. Executed activities, concrete data values, and resources and persons are represented at the instance level.
To organize the complexity of business process scenarios, a set of similar entities at the instance level are identified and classified at the model level.
For instance, a set of similar business process instances are classified and rep- resented by a business process model. In object modelling, a set of similar entities is represented by a class, and in data modelling using the Entity Re- lationship approach, a set of similar entities is represented by an entity type, and similar relationships between entity types are represented by a relation- ship type.
M3: Meta-Metamodel
M2: Metamodel
M1: Model
M0: Instance
Instance-of describes
Instance-of describes
Instance-of describes
Notation
expresses
Fig. 3.2.Levels of abstraction
Models are expressed in metamodels that are associated with notations, often of a graphical nature. For instance, the Petri net metamodel defines Petri nets to consist of places and transitions that form a directed bipartite graph.
The traditional Petri net notation associates graphical symbols with meta- model elements. For instance, places are represented by circles, transitions by rectangles, and the graph structure by directed edges.
In data modelling, the Entity Relationship metamodel defines entity types, relationship types, and connections between them. Typical graphical notations of the Entity Relationship metamodel are rectangles for entity types and di- amonds for relationship types, connected by lines.
While often there is one graphical notation for one approach, a one-to-one correspondence between notation and metamodel is not mandatory. In a Petri net, the concept of a transition could also be represented by another symbol in a graphical notation. There are different notations for representing Petri
nets, which differ in the graphical representation of transitions. While some use rectangles, others use solid bars.
Therefore, it is important to distinguish between the concepts of a mod- elling approach and the graphical notation used to represent these concepts.
The complete set of concepts and associations between concepts is called meta- model. A metamodel becomes useful if there is a notation for this metamodel that allows expressing models in a convenient way that allows communication between stakeholders in the modelled real-world situation.
The different levels of abstraction and their relationships are shown in Figure 3.2. A notation associated with a metamodel allows expressing the concepts of that particular metamodel. Each model is described by a meta- model, and is expressed in a notation associated with the metamodel.
3.2.2 Vertical Abstraction
Vertical abstraction in business process modelling is depicted in Figure 3.3, where distinct modelling subdomains are identified. As depicted, process mod- elling is at the centre of the modelling effort, because it also integrates the modelling efforts that are conducted in the other subdomains.
Process Modelling Business Process Modelling
Information Modelling
Organization Modelling Function
Modelling
IT Landscape Modelling
Fig. 3.3. Business process modelling includes multiple modelling domains, inte- grated by process modelling
Function modelling, data modelling, organization modelling, and mod- elling of the operational information technology landscape are required to provide a complete picture of a business process. While these subdomains are the most important ones, additional subdomains can be defined if they are relevant.
The functional model investigates the units of work that are being enacted in the context of business processes. The specification of the work can be done at different aggregation levels, from coarse-grained business functions to fine- granular functions at the operational level that are realized by knowledge workers and information systems.
The specification of these functions can be informal, using English text or formal, using syntactic or semantic specifications of functions. While informal descriptions are mostly done at the coarse business level, more precise speci- fications are required in the software layer when it comes to implementation of certain functions using information systems.
The investigation and proper representation of data in business processes is important, because decisions made during a business process depend on particular data values. Also data dependencies between activities need to be taken into account in process design, to avoid situations in which a function requires certain data not available at that time.
The proper representation of the organizational structure of a company is an important requirement. Activities in the business process can then be associated with particular roles or departments in the organization. Many ac- tivities in a business process are performed by or with the assistance of infor- mation systems. The operational information technology landscape, i.e., the information systems, their relationships, and their programming interfaces, needs to be represented to use the functionality provided by the information systems.
Process modelling defines the glue between the subdomains. A process model relates functions of a business process with execution constraints, so that, for instance, the ordering and conditional execution of functions can be specified. Data aspects are covered because particular process instances may depend on the structure and value of data involved in a particular busi- ness process. For example, in a credit approval business process, the type of approval depends on the credit amount requested. In addition, data depen- dencies between activities need to be taken into account in process model design.