METHODOLOGICAL EXTENSIONS FOR SEMANTIC BUSINESS

PROCESS MODELING

David de Francisco, Henar Muñoz, Noelia Pérez, Javier Martínez

Telefonica Research & Development, Valladolid, Spain

Ivan Markovic

SAP Research, Karlsruhe, Germany

Keywords: Business Process Modeling, Methodology, Reusability, Validation.

Abstract: Semantic Business Process Management (SBPM) aims, among other advantages, to facilitate the reuse of

knowledge related to the definition of business processes, as well as to provide an easier transition from

models to executable processes by applying semantic technologies to BPM. In this article the authors focus

on extending the scope of knowledge being reused from executable processes to semantic models' scope.

This is done by providing some methodological extensions to existing BPM methodologies in order to take

advantage of semantic technologies during business process modeling.

1 INTRODUCTION

Business Process Management (BPM) is an

approach to manage the execution of information

technology-supported business operations ().

Semantic Business Process Management (SBPM)

(Hepp et al, 2005) extends the BPM approach by

adopting Semantic Web technologies in order to

bridge the gap between the business and technical

perspective on supporting information systems. In

this context, semantics tries to overcome i) the lack

of formal representation of process models, which

results in a more difficult transition from models to

executable processes, ii) the unnecessary complexity

of current business process models, and iii) a lack of

reutilization which implies important time-to-market

increase.

A simplified comparison between BPM and

SBPM life cycles is depicted in Figure 1. BPM life

cycle (depicted in continuous arrows) starts with

process design (Weske et al, 2004) made by business

analysts, which provides process models (1). These

models are further translated by technicians (2) into

executable processes (3), which are integrated with

previous processes defined within the company by

technicians (4). Semantic BPM life cycle (depicted

in dashed arrows) designs semantically annotated

models (1'), enabling reuse of previous models and

the validation of their business context (2'). These

models can be translated into executable semantic

processes with less (or no) interaction from

technicians (3'). The executable semantic processes

can be composed (as Web services are) with other

semantic processes in a more flexible way due to

their uniform annotation (4').

Figure 1: Comparison between BPM (continuous line) and

Semantic BPM Life Cycles (dashed arrows).

Focusing on design steps (upper part of the

picture), a need for adaptable methodologies to drive

business process (BP) modeling is presented in

(Roser and Bauer, 2005). Modeling is covered by

410

de Francisco D., Muñoz H., Pérez N., Martínez J. and Markovic I. (2008).

METHODOLOGICAL EXTENSIONS FOR SEMANTIC BUSINESS PROCESS MODELING.

In Proceedings of the Tenth International Conference on Enterprise Information Systems - ISAS, pages 410-415

DOI: 10.5220/0001718304100415

 SciTePress

several BPM methodologies, such as ARIS (Scheer,

2000), (Scheer, 1999), IBM (Wahli et, 2007), (IBM,

2006). However, the lack of a uniform notation in

modeling tools brings model inconsistencies. That

stimulated new proposals to share BP models

(Yamamoto et al, 2005), to improve reusability and

flexibility in BPM (Yao et al, 2006) or to optimize

BP design in order to empower process redesign

(Zhou and Chen, 2003).

Semantic technologies can overcome the lack of

uniform representation, empowering the reusability

of previous models as previously argued. In

addition, semantic BP modeling offers some

inherent techniques that are obviously not covered in

current BPM methodologies, such as semantic

annotation (Born et al, 2007), discovery (Markovic

and Karrenbrock, 2007) , querying (Markovic et al,

2007) and composition of processes, in order to

favor the reuse of BP models (Markovic and Pereira,

2007). That makes a specific coverage of such

techniques necessary for semantic BPM

methodologies.

The proposal of this paper focuses on the

modeling phase, where a big gap in the translation

between business requirements to process models

still exists (Hepp et al, 2005). Therefore, we believe

that a methodological coverage of steps 1' and 2' of

Figure 1 is also needed. To address this

requirement,,we propose some extensions to current

semantic Business Process modeling methodologies

which can favor the reuse of business know-how.

These extensions add some sub-phases which

complement existing methodologies and are

currently being implicitly used by business analysts,

such as BP patterns and model validation against

business policies.

The authors will present a brief state of the art of

current semantic and non-semantic BP modeling

methodologies (Section 2). In Section 3 we illustrate

the proposed methodology extensions with examples

from telecommunication sector, as one of the

business domains which could obtain more benefits

from the better reusability due to the strong time-to-

market requirements of this sector. The article

concludes with an outlook on the usage of these

methodology extensions in Section 4.

2 STATE OF THE ART

BP modeling phase is covered by most of the

existing methodologies, e.g. ARIS (Scheer 200),

(Scheer, 1999), IBM (Wahli et al, 2007), (IBM;

2006). The modeling life cycle is mainly formed by:

requirement analysis from business analysts, process

modeling by using a formal language, simulation

and redesign (IBM, 2006). In addition, ARIS defines

the five views of the knowledge (mainly focused on

IT level) used during BP Modeling activities

(Scheer, 2000): data (information objects and their

relationships), organization (organizational

structures and their relations), function (activities),

product (input and output produced by activities)

and control (process flow). However, the knowledge

related to BP modeling is broader than current

methodologies and languages can represent (Mou et

al, 2004). Extending the representable knowledge of

current methodologies and languages can provide

several benefits to overcome the aforementioned

weaknesses.

Within the SUPER project (ip-super.org), a

methodology which covers the complete SBPM life

cycle (from modeling to execution and analysis) has

been defined (Fantini et al, 2006), and a proposal of

methodological guidelines for modeling and

configuration phases has been made (Weber et al,

2007). This proposal's objective is to facilitate the

transition from BP models to executable processes,

as well as the reuse of workflow (steps 3' and 4' of

Figure 1). However, we argue that focusing BP

modeling on getting only implementation benefits i)

doesn't allow business analysts to fully define

models, ii) doesn't capture all knowledge from a

business perspective which is usually very relevant

to a company and iii) misses a great opportunity to

reuse and extend the business knowledge, as

presented in the following section.

3 LIFE CYCLE PROPOSAL FOR

SEMANTIC BP MODELING

In this section, authors propose a life cycle for

semantic business process modeling. This life cycle,

depicted in Figure 2, is based on the spiral life cycle

model first proposed by Boehm (), which is widely

adopted by BPM community due the dynamic nature

of BPs and their consequent redesign cycle. The use

of a continuous evaluation and improvement process

(such as CMMI (Institute, 2007)) is recommended in

order to define the procedures to ensure the quality

of any artifact produced during semantic BP

modeling (ontologies, models, patterns, etc.), and

thus depicted in the outer ring of the picture.

However, the definition of such a process is beyond

the scope of this article.

METHODOLOGICAL EXTENSIONS FOR SEMANTIC BUSINESS PROCESS MODELING

411

Figure 2: Semantic Business Process Modeling Life Cycle.

Phases, depicted as the inner ring, and sub-

phases (next ring), are based on current BP modeling

and software engineering life cycles (Pressman,

2005). Although some sub-phases are extensions to

most commonly used life cycles, the major

contribution of this life cycle comes from the

application of ontologies, semantic tools and

techniques, depicted in the third ring of the picture

by a triangle, a hammer and a hand respectively. In

following subsections we present each of the phases

and sub-phases of the life cycle, providing a

description, products which will be provided by this

phase, ontologies and tools to be used, and the

application and expected advantages of semantic

techniques within each phase.

3.1 Requirements Analysis Phase

During the Requirements Analysis phase, business

analysts collect all the relevant information for the

BP design and further implementation. This

information comes from various sources (e.g. the

company's strategy, marketing and product

departments, final customers, partners, etc.), and has

to be collected and documented by analysts.

3.1.1 Requirements Capture

Requirements Capture is the phase in which a

business analyst collects all the relevant information

for a BP design and extracts requirements for the

BP. The information taken into account comes from

heterogeneous sources (e.g. meeting minutes,

technical and business documents, etc.) and a

common understanding between analysts and

requirement providers is needed. The study of this

information will discover business and technical

needs that will be documented as requirements

during the next sub-phase. During this phase, while

technical specifications are being defined,

knowledge is exchanged between business analysts,

people from different departments/companies and

technicians.

3.1.2 Requirements Documentation

This phase involves the documentation of

requirements captured in the requirement analysis. It

is composed by the requirement classification to

support their traceability, as well as the refinement

of the requirements specification, defining the

functional and non-functional objectives to be

covered by the BP. Output of this sub-phase is a

requirement analysis document in which

requirements for the BP modeling are documented

as stated before.

There is no systematic way of documenting

requirements. Most often the business analysts use

Microsoft Word, Powerpoint or spreadsheets for

documentation purposes. By providing a shared

model (see 3.2.2), ontologies have the potential to

structure the method of documenting requirements,

enable their common understanding and provide the

possibility for automated analysis. An ontology for

requirements documentation as in (Jinxin et al,

1996) would allow e.g. for detecting redundancies

and conflicts in the requirements specification. It

would also enable gap analysis and easier

traceability of requirements across the specification,

by answering queries such as: “What is the source of

this requirement?”

3.2 Modeling Phase

After requirements have been specified, the business

analyst provides several artifacts as a result of the

BP modeling. These artifacts are ontologies, BP

patterns, goals and KPIs, and finally concrete BPs

which will be translated to executable processes and

run in further steps not covered in this article.

3.2.1 Ontologies Modeling

Requirement analysis phase produces a list of

documented requirements which might affect the

business ontologies being used during the modeling

and validation phases (e.g. redefinition or new

concepts, relationships, etc.). Business ontologies

model different perspectives of processes, where we

ICEIS 2008 - International Conference on Enterprise Information Systems

412

reuse the ontology framework described in

(Markovic and Pereira, 2007), and domain-specific

information (domain ontologies). The output of this

sub-phase is the refinement of business ontologies

according to the specific scenario. Note that many of

the domain ontologies can make use of existing

standards, like NGOSS (Reilly and Creaner, 2006)

in the case of telecommunications sector.

3.2.2 Patterns Modeling

BP patterns are abstract BPs which are not fully

defined in terms of concrete tasks and services, and

thus can not be executed. These patterns capture the

first draft of a process, making emphasis on the

business goals and leaving the concrete definition of

processes to a further step. They represent a solution

to a well known problem, and a base to enable the

extension to a concrete problem (as software design

patterns do (Gamma et al, 1995)), providing best

modeling practices.

The first step in defining a business process is to

define objectives to achieve. This definition is

commonly done by the definition of business

process patterns, which can be defined from

previous patterns or from scratch. BP patterns are

implicitly used by business analysts when they want

to define what a process should achieve without

defining how this will be done. The patterns define

high level goals (or milestones) and a simple

workflow which connects them.

The objective of the formalization of these high-

level models in our methodological extensions is to

provide best practices for other business analysts and

a common base for the specification of BPs which

share a same sub-domain (e.g. all BP of a given

product family share common features in their

design).

Patterns are annotated with the context of their

usage which is comprised of a business function, a

business goal and a business domain. These

annotations allow us to query for patterns in the

early stages of modeling in order to provide

modeling guidance. An example query for business

pattern can be formulated in the following way:

“Give me all business patterns related to Fulfillment

Business Function and Client

and Product Business

Domain where Business Goals involved are

profileObtained

and serviceActivated”.

3.2.3 Goals and KPI Modeling

After the definition of the objectives which the BP

being modeled has to accomplish, a business analyst

usually refines those objectives in terms of business

goals at the operational level (more concrete than the

ones defined for the pattern), and assigns them to

corresponding key performance indicators (KPIs).

KPIs define the metrics used to monitor and measure

the performance of business processes during

execution time. Business goals and KPIs can be

reused from previous models. The output of this

phase will be the formalization of both business

goals and KPIs, annotated according to the

ontologies defined in the ontology modeling sub-

phase.

Formal modeling of goals allows us to perform

goal-based analysis of process models in order to

detect redundancies and conflicts in process

specifications. In addition, we could follow the

dependencies (e.g. identifying which goals support

or hinder the observed one) in the goal model. It also

allows for improved traceability when changes in the

environment occur. Through reflecting the changes

on business goals, we are able to easily identify the

processes which need to be adapted to the new

requirements.

3.2.4 Process Modeling

Once business process objectives are clear, and the

metrics used to measure its performance defined, the

process is defined. Tasks and workflow can be

defined by either i) deriving from previous BP

patterns, ii) extending or refining previous BP

models, iii) editing directly, or iv) any combination

of the previous options, since BP modeling is often

made in several steps which can mix up previous

approaches. Once the process is defined, it is

semantically annotated according to the ontologies

defined in the ontology modeling sub-phase. Once

the process is finished, we will have a complete BP

model including the following artifacts: a BP model

with semantic annotations, goal(s) and KPI it should

fulfill, BP pattern(s) which derives from, if any, and

ontologies which formalize the knowledge used to

create the aforementioned artifacts.

The business process ontology (Markovic and

Pererira 2007) and the domain ontologies defined in

section 3.2.1 are used in querying for business

process artifacts, which supports decision making

and facilitates reuse of modeling artifacts (Markovic

et al, 2008). Some example queries for the decision

making support scenario include: “Give me all

processes in the fulfillment area”, “Which processes

use system x?”. Since process modeling is a

complex activity, the reuse of existing models and

model components makes sense in all stages of

modeling. When reusing existing modeling artifacts,

METHODOLOGICAL EXTENSIONS FOR SEMANTIC BUSINESS PROCESS MODELING

413

the analyst can reuse process fragments (self-

contained, coherent building blocks of a process

model with a clear business meaning) or existing

process models which are similar to the desired

model. Moreover, the analyst can substitute an

existing process fragment based on redesign goals or

auto-complete an underspecified model, by making

queries on process annotations in the modeling tool

(Markovic et al, 2008).

3.3 Validation Phase

Validation of BP models is a crucial phase in which

it is ensured that the BP designed effectively covers

the requirements captured in the first phase from

both a functional and business perspective. Besides,

quality of the model must be checked, ensuring that

the model designed will derive in an executable

process with high performance, and that the model is

conceptually correct.

3.3.1 Model Quality Validation

This sub phase checks the model quality according

to a set of metrics. These metrics heavily depend on

the company and the continuous evaluation and

improvement model they are following. Metrics can

include complexity of the model, structure of the

model, modularization, or cognition (Volker Gruhn,

2007).

Annotating processes using a common

vocabulary (provided by ontologies from section

3.2.1) enables semantic evaluation of process

models and leads to improved readability of the

models not only for human beings but also for

machines. This enables automation envisioned by

the Semantic Business Process Management

methodology. Furthermore, by using a shared

vocabulary the abstraction conflicts are eliminated

and problems caused by synonyms and homonyms

are avoided, resulting in models of higher quality.

3.3.2 Functional Validation

This sub phase checks the coverage of functional

requirements that the BP has to accomplish.

Additionally, the workflow performance is usually

tested by the simulation of the model, in order to

detect possible bottlenecks at early stages of the

BPM life cycle. The result of the validation brings

new requirements for improving the BP model,

which are taken into account in subsequent modeling

iterations.

In this phase, we can utilize the formalization of

the behavioral (dynamic) perspective of processes

from (Markovic and Pereira, 2007) in order to

perform formal verification of the correctness of the

model. This includes deadlock and liveness checks

on the model by using techniques from (Puhlmann,

2006) and also the step-by-step simulation of the

process behavior (Puhlmann and Bog, 2006).Based

on the results of the verification, business analysts

can perform necessary corrections on process

models in the early stages of the BPM life cycle.

3.3.3 Business Validation

Real BPs do not only have to accomplish certain

functional requirements, but also are influenced by

business policies and rules which are derived from

the company strategy. Business policies

orthogonally apply to all business processes of the

company and can be mandatory or optional.

Mandatory policies must be correctly addressed in

BP models, while conditional ones are suggestions

to improve or complement the model which can or

can not be taken in consideration. Business rules

affect the execution of the process, defining

conditions which drive the execution of the

workflow. Checking both elements usually provide

new requirements for later modeling iterations as

well.

Business policies can be annotated with the

context of usage (business function, goal, domain) in

order to retrieve all policies (both mandatory and

conditional) which match context annotations of the

model being checked. An example query can be

formulated as: “Give me all business policies for

Digital Asset Management

domain for minors where

Business Goal associated belongs to Fulfillment”.

Information retrieved includes a textual explanation

of the business policy as well as a control definition

(subprocess) which explains how this policy should

be included or taken into account in the model being

checked. This helps us to ensure the correctness of

the designed models. In addition, ontologies can be

used to formalize business policies and the derived

business rules in order to enable semi-automatic

compliance checking of existing process models

against relevant policies.

4 CONCLUSIONS AND FUTURE

WORK

In this article, the authors have proposed new

methodology extensions which emphasize the

application of ontologies, by semantically enhanced

tools and techniques with the aim of reusing

ICEIS 2008 - International Conference on Enterprise Information Systems

414

business knowledge and therefore creating models

of higher quality, speeding up business process

modeling while reducing error-proneness of the task.

These extensions complement current

methodologies, adapting them to the use of

semantics in business process management. In the

near future, the authors will design a validation plan

for these extensions, with the aim of extracting some

empirical conclusions about the usage of the

proposal within the telecommunication sector.

REFERENCES

Boehm, B. W. (1988). A spiral model of software

development and enhancement. Computer, 21(5):61–72.

Born, M., Dörr, F., and Weber, I. (2007). User-friendly

semantic annotation in business process modeling. In

Proc. of the Hf-SDDM Workshop, December 2007.

Fantini, P., Savoldelli, A., Milanesi, M., Carizzoni, G.,

Koehler, J., Sebastian Stein and, Ralf Angeli and,

M. H., Roman, D., Brelage, C., and Born, M. (2006).

Semantic business process life cycle. SUPER Project

Deliverable.

Gamma, E., Helm, R., Johnson, R., and Vlissides, J.

(1995). Design patterns: elements of reusable object-

oriented software. Addison-Wesley Longman

Publishing Co., Inc. Boston, MA, USA.

Hepp, M., Leymann, F., Domingue, J., Wahler, A., and

Fensel, D. (2005). Semantic business process

management: A vision towards using semantic web

services for business process management. In Proc. of

the ICEBE 2005.

IBM (2006). Best Practices for Using WebSphere

Business Modeler and Monitor. IBM Redbooks.

Institute, S. I. (2007). Cmmi web site.

http://www.sei.cmu.edu/cmmi/index.html.

Jinxin, L., Mark, F., and Bilgic, S. (1996). A requirement

ontology for engineering design. Manuscript,

September, 1996.

Markovic, I. and Karrenbrock, M. (2007). Semantic web

service discovery for business process models. In

Proc. of the Hf-SDDM Workshop, December 2007.

Markovic, I. and Pereira, A. (2007). Towards a formal

framework for reuse in business process modeling. In

Business Process Management Workshops, September

2007.

Markovic, I., Pereira, A. C., de Francisco, D., and Muñoz,

H. (2007). Querying in business process modeling. In

Proc. of the SeMSoC Workshop, September 2007.

Markovic, I., Pereira, A. C., and Stojanovic, N. A

framework for querying in business process modeling.

In Proc. of the Multikonferenz Wirtschaftsinformatik,

February 2008).

Mou, Y., Cao, J., and Zhang, S. (2004). A process

component model for enterprise business knowledge

reuse. In Proc. of the.SCC 2004, pages 409 – 412.

Pressman, R. S. (2005). Software Engineering: A

Practitioner's Approach. McGraw-Hill Professional,

6th edition.

Puhlmann, F. (2006). A tool chain for lazy soundness. In

Business Process Management.

Puhlmann, F. and Bog, A. (2006). A tool for the

simulation of pi-calculus systems. In Open. BPM

2006NGOSS distilled, TeleManagement Forum, 2006.

Roser, S. and Bauer, B. (2005). A categorization of

collaborative business process modeling techniques. In

Proc. of the CEC Workshops, 2005., pages 43 – 51.

Scheer, A.-W. (1999). ARIS - business process

frameworks 3rd Edition. Springer Verlag.

Scheer, A.-W. (2000). ARIS - business process modeling

3rd Edition. Springer Verlag.

Smith, H. and Fingar, P. (2003). Business Process

Management: The Third Wave. Meghan-Kiffer Press.

Volker Gruhn, R. L. (2007). Approaches for business

process model complexity metrics. In TEchnologies

for Business Information Systems, pages 13–24.

Springer.

Wahli, U., Avula, V., Macleod, H., Saeed, M., and

Vinther, A. (2007). Business Process Management:

Modeling through Monitoring Using WebSphere

V6.0.2 Products. IBM Redbooks.

Weber, I., Hoffmann, J., Mendling, J., and Nitzsche, J.

(2007). Towards a methodology for semantic business

process modeling and configuration. In Proc. of the

SeMSoC Workshop, September 2007.

Weske, M., van der Aalst, W. M. P., and Verbeek, H.

M. W. (2004). Advances in business process

management. Data Knowl. Eng., 50(1):1–8.

Yamamoto, R., Yamamoto, K., Ohashi, K., and Inomata,

J. (2005). Development of a business process

modeling methodology and a tool for sharing business

processes. In Proc. of the 12th APSEC '05., pages

1530–1362.

Yao, Q., Chen, Z., and Wang, H. (2006). Improving

flexibility and reusage of business process

management: the role of cased-based reasoning

technique. In Proc. of the ICEBE '06, pages 187 – 194.

Zhou, Y. and Chen, Y. (2003). The methodology for

business process optimized design. In Proc. of the

29th IECON '03., pages 1819 – 1824.

METHODOLOGICAL EXTENSIONS FOR SEMANTIC BUSINESS PROCESS MODELING

415