Combined Variability Management of Business Processes and Software

Architectures

Andreas Daniel Sinnhofer

, Andrea H

oller

, Peter P

uhringer, Klaus Potzmader

, Clemens Orthacker

Christian Steger

and Christian Kreiner

Institute of Technical Informatics, Graz University of Technology, Austria

NXP Semiconductors, Gratkorn, Austria

{a.sinnhofer,andrea.hoeller,christian.kreiner,steger}@tugraz.at, p.puehringer@inode.at,

{klaus.potzmader, clemens.orthacker}@nxp.com

Keywords:

Software Product Lines, Feature Oriented Modeling, Business Process Variability Management, Software

Conﬁguration

Abstract:

Nowadays, organizations are faced with the challenge of surviving in a highly ﬂexible and competitive mar-

ket. Especially the domain of Internet of Things is affected by short product cycles and high pricing pressure.

Business Process oriented organizations have proven to perform better regarding highly ﬂexible markets and

fast production cycles. However, especially industries focused on low cost IoT systems are facing big prob-

lems if the according business processes are not aligned with the business processes. Consequently, a lot of

development effort is spent for features which are never addressed by any business goal. With this work, we

propose to use a combined variability management in order to efﬁciently address product variability on the

organizational level as well as on the technical level.

1 INTRODUCTION

We are living in an ever changing and interconnected

world. The dawn of the Internet of Things (IoT) fur-

ther increases the trend for organizations to deliver

feature rich systems in high quantities and at low

costs. Due to this pricing pressure, methods have to be

investigated which allow modular and highly conﬁg-

urable systems such that the products can be adapted

to the current requirements of the market.

Business Process (BP) oriented organizations are

known to perform better regarding highly ﬂexible de-

mands of the market and fast production cycles (Mc-

Cormack and Johnson (2000); Hammer and Champy

(1993); Valena et al. (2013); Willaert et al. (2007)).

This is achieved by introducing a management pro-

cess during which business processes are modeled,

analyzed and optimized in iterative improvement pro-

cesses. During recent years, business process man-

agement is further coupled with a workﬂow manage-

ment in order to monitor the correct execution of the

process and to integrate responsibilities to the process

models. In order to react to changing requirements,

context aware business process modeling techniques

were introduced by Saidani and Nurcan (2007): Flex-

ibility is gained through the analysis of the context

states of the environment which are mapped to the ac-

cording business processes and their related software

systems. The problem with such approaches is that

the used software systems are often developed inde-

pendently from each other, although they share a sim-

ilar software architecture.

Software Product Lines (SPL) have proven to be

essential for the development of ﬂexible product ar-

chitectures which can be adapted to the current re-

quirements (Pohl et al. (2005)). Through the use of

a common architecture and reusable product features,

SPL promises to deliver high quality products while

simultaneously maintaining low development costs.

The most critical phase during the design and the im-

plementation of a product line is the identiﬁcation of

the variable parts and the common parts of the prod-

uct family (Pohl et al. (2005)). Consequently, a lot of

effort is invested to identify the domain requirements

of the ﬁnal product portfolio. Equally important is the

selection of the according features during the applica-

tion engineering: It has to be guaranteed, that the cus-

tomer requirements are fully met; further, all unnec-

essary features need to be excluded in order to ensure

low productions costs of the ﬁnal product. Since the

identiﬁcation of the domain requirements is usually

carried out from developers, an integrated view of the

organizational goals is often missing. Thus, the efﬁ-

ciency of the product line is reduced since additional

effort needs to be invested to conﬁgure the product

according to the current requirements.

This work focuses on the development of a frame-

work which aims to enforce a link between the vari-

ability of the business processes and the variability of

the product platform. As such, we propose a com-

bined variability modeling in which the requirements

for the organization as well as for the development

of the product platform are identiﬁed together. Af-

ter identifying the requirements, order processes are

designed which reﬂect the possible product conﬁgu-

rations that can be ordered by a customer. These vari-

able order processes are further used to automatically

trigger the product customization process in order to

reduce the production costs of the ﬁnal product. This

work is based on our previous works in which we

already deﬁned systems for the modeling variability

of business process models (Sinnhofer et al. (2015))

as well as a framework for generating software con-

ﬁgurations based on order processes (Sinnhofer et al.

(2016, 2017)).

This work is structured in the following way: Sec-

tion 2 summarizes basic concepts about business pro-

cess modeling as well as software product line engi-

neering. Section 3 summarizes out approach to link

variable order process models to variable software ar-

chitectures in an automatic way. In Section 4 we de-

scribe how we applied the introduced concepts in an

industrial use case and present a simpliﬁed example

for illustration purposes. Since the identiﬁcation of

business drivers is essential for an organization to sur-

vive in a competitive market, we show in Section 5

how we were able to identify improvement opportu-

nities, by analyzing the results of our framework. We

conclude this work by presenting related work in Sec-

tion 6 and a summary in Section 7.

2 BACKGROUND

The current section summarizes the basic concepts of

Software Product Line Engineering and Business Pro-

cess Modeling, which are applied in this work. Fur-

ther, our previous publications – which are forming

the foundation of this work – are brieﬂy summarized.

2.1 Software Product Line Engineering

Software Product Line Engineering (SPLE) applies

the concept of product lines to software products. As

a consequence, SPLE promises to create diverse and

high quality software products of a product family in

short time and at low costs Pohl et al. (2005). Instead

of writing software for every individual system, soft-

ware products are automatically generated by com-

bining the required domain artifacts. The principal

concept can be split into two main phases: the Do-

main Engineering and the Application Engineering

(Pohl et al. (2005); Weiss and Lai (1999)).

The Domain Engineering is the phase in which the

variabilities and the commonalities of the according

domain are identiﬁed and the reusable domain arti-

facts are implemented. Domain artifacts are devel-

opment artifacts like the software architecture or the

software components. One essential phase during the

domain engineering is the requirements engineering

process, in which a domain analysis has to be per-

formed in order to identify the requirements of the

ﬁnal product. Based on the identiﬁed requirements,

the domain is usually modeled by using a Feature Ori-

ented Design Modeling (Kang et al. (1990)) approach.

During this process, Feature Models are used to ex-

plicitly describe all features of a product, their rela-

tionships, dependencies and additional restrictions.

The Application Engineering is the phase during

which the ﬁnal products are created by combining the

domain artifacts in a meaningful manner. This is en-

forced by the use of domain constraints which were

modeled during the Domain Engineering phase. In

difference to the Domain Engineering, the Applica-

tion Engineering is mainly focused on reusing arti-

facts rather than the implementation of new artifacts.

In the ideal case, this phase makes use of software

generators to automatically derive product variants

without the need of implementing any new logic. The

amount of reused domain artifacts heavily depends on

the application requirements and gives an estimate on

the efﬁciency of the product line. Hence a major con-

cern of the application engineering is the detection of

deltas between the application requirements and the

available capabilities of the product line.

2.2 Business Process Modeling

Business Processes (BP) are a speciﬁc sequence of

activities or (sub-) processes which are executed in a

certain order to create an amount of value to the cus-

tomer Hammer and Champy (1993). In this work, we

use the concept deﬁned by

Osterle (1995) to model

BPs: BPs are modeled in different layers, where the

top level (macroscopic level) is a highly abstract de-

scription of the overall process and the lower-levels

(microscopic levels) are more detailed descriptions

of the sub-processes. A reasonable level of detail is

reached, if the process description on the lowest lev-

els can be used as work-instructions for the responsi-

Combined Variability Management of Business Processes and Software Architectures

ble employees. This leads to the fact that the higher

levels of the process description are usually indepen-

dent of the production facility and the supply chains;

while the lower levels are highly dependent on the

production facility and its capabilities. As a conse-

quence, the macroscopic level is more stable with re-

spect to changes and can be reused in different con-

texts and production environments. The microscopic

levels need to be updated in order to reuse them in dif-

ferent contexts. Variability of such process structures

can be modeled through a variable process structure

(i.e. by adding/removing activities in a process) or

by replacing process reﬁnements with different sub-

processes. In general, three main types of business

processes can be distinguished (see Association of

Business Process Management Professionals (2009)):

• Primary Processes: Each of the process activities

adds a speciﬁc amount of value to the value chain.

Consequently, such processes are also often re-

ferred to as Core Processes since the customer

value is directly reﬂected in these processes.

• Support Processes: Are processes which are de-

signed to support the Primary Processes like man-

aging resources or infrastructure. Such processes

do not directly add value to the customer but are

essential to ensure the proper execution of the Pri-

mary Processes.

• Management Processes: Are designed to mon-

itor and schedule business activities like the exe-

cution of Primary Processes or Support Processes.

While Management Processes do not directly add

value to the customer, they are designed to in-

crease the efﬁciency of the business activities.

Domain speciﬁc modeling languages are usually

used to model all the activities, resources and respon-

sibilities within a Business Process. In the scope of

this work, the Business Process Model and Notation

(BPMN, Object Management Group (2011)) is used

to model processes, but the general concept of this

work is not limited to this notation. The key concepts

which are used in this work, are summarized below

(Object Management Group (2011); Sinnhofer et al.

(2017)):

Events: Occurs during the execution of a process

and may affect the ﬂow of the process. For exam-

ple, the start or the completion of an Activity are typ-

ical events that occur in every process. According to

the BPMN speciﬁcation Object Management Group

(2011), events are used only for those types, which

affect the sequence or timing of activities of a pro-

cess.

Activities: An Activity is a speciﬁc amount of

work that has to be performed by the company – or an-

other organization – during the execution of a process.

Two different types of activities can be distinguished:

Atomic activities (i.e. a task) and non-atomic activi-

ties (e.g. sub-processes).

Gateways: Are used to control how the process

ﬂows through different sequences of activities. Each

gateway can have multiple input and/or output paths.

One example is a decision, where out of many possi-

bilities, only one path is selected. The selection of the

paths can be coupled to conditions or events which

are triggered during the execution of the process.

Data: Data objects represent the information ﬂow

through the process. Two types of Data objects can

be distinguished: Input Data that is required to start

a speciﬁc activity and Output Data which is produced

after the completion of an Activity.

Pool and Lanes: Are used to model responsibili-

ties for speciﬁc activities in a process. Responsibili-

ties can be usually assigned to an organization, to spe-

ciﬁc roles or even dedicated employees.

It is common practice for organizations to main-

tain multiple variants of business processes which are

based on a common template (Rosa et al. (2017)).

This leads to the situation that similar process vari-

ants are created through a copy and clone strategy. As

a consequence, maintaining these process variants is a

time consuming tasks since every single process vari-

ant has to be manually updated by the according pro-

cess designer. Besides the additional maintenance ef-

fort, using copy and clone strategies also have a nega-

tive inﬂuence on the process documentation. To solve

these issues, we proposed a Software Product Line

approach for the derivation of process variants from

business process models (see Sinnhofer et al. (2015,

2016, 2017)). The concept can be split into four dif-

ferent phases:

Process modeling: During the process modeling,

process designers are responsible to design process

templates. The process templates are designed us-

ing the BPMN notation and additional artifacts are

integrated like documentation templates, responsible

roles, resource allocations, etc. The process templates

are designed in an appropriate BPM Tool to fully sup-

port the process designers during the design process.

The process of designing the process templates and

the process of creating the according domain model

goes hand in hand to ensure that the created templates

can be reused in many different contexts.

Domain modeling: During this process, the cre-

ated templates are imported into a Software Product

Line tool and translated into a so called feature model

(see Sub-Section 2.1). During the creation of the fea-

ture model, it has to be decided which parts of the pro-

cess are designed to be variable and which parts are

Seventh International Symposium on Business Modeling and Software Design

static. For illustration purposes, the following exam-

ple is given: A company creates car parts for two ma-

jor car manufacturers. While the overall process for

creating the car parts is identical for both customers,

different production planning strategies are used to

optimize the material usage (e.g. stock size, etc.).

As a consequence, the production planning strategy

has to be designed variable such that the overall pro-

cess model can be reused for both customers. The

deﬁnition of variable parts and static parts happens

in close cooperation with the according process de-

signers and may even lead to a re-iteration of the ﬁrst

phase if some process templates need to be adapted.

Not every combination of variants may create mean-

ingful process variants. As a result, a comprehensive

list of restrictions and rules has to be designed as well

to guarantee that only valid and meaningful process

variants can be created by the product line. The list of

rules and restrictions has to be deﬁned ﬂexible as well,

since not every restriction may be identiﬁed when the

process model is created. Consequently, re-iterations

of the restriction model are common after collecting

evaluation data from the execution of the process.

Feature selection: Based on the current require-

ment of the organization, process variants are created

using the created feature model. This is done be se-

lecting the required features from the model and by

translating this feature selection to a valid business

process structure. To ensure an automatic transforma-

tion, generators have to be developed which are able

to translate between the business process model and

the feature model. The deﬁned rules and restrictions

are enforced during this process to guide the domain

expert in selecting a meaningful set of options. To

continue the example from above, two process vari-

ants may be created for the two customers. The only

difference between the processes is the production

planning strategy.

Maintenance and Evolution: One of the most

important phases is the maintenance and evolution

phase: To be highly ﬂexible and adaptive to the cur-

rent requirements of the market, processes and their

according models have to be continuously improved

and adapted. As such, the derived processes are moni-

tored by production experts during the time in use and

evaluated against the requirements. Based on the col-

lected data, feature selections can be improved or pro-

cess improvement processes can be scheduled. Dur-

ing a process improvement process, process templates

are updated or created from the process designers and

integrated into the existing feature model. Through

the capabilities of the Software Product Line tool, it

is possible to automatically propagate the changes of

the process templates to every instance. As a conse-

quence, no time consuming and error prone manual

maintenance process is necessary to adapt all the ex-

isting process variants. Since it may happen that some

of the process variants shall not be updated in case of

changes, version control can be used to explicitly state

which version of a template shall be used.

Our today’s business environment is focused on

creating sustainable value by increasing the revenue

of business drivers. The identiﬁcation of such busi-

ness drivers, or the identiﬁcation of the drivers which

are able to destroy value is an essential step for an or-

ganization Strnadl (2006). Otherwise, staying com-

petitive or even survive on a ﬂexible market is not

possible. The combination of business variability and

software variability is a promising way to improve the

identiﬁcation of such drivers. Further, having a com-

bined view of the requirements helps to increase the

overall efﬁciency of the product line.

3 COMBINED VARIABILITY

MODELING

The goal of this work is an automatic generation of

software products based on the product order. In or-

der to achieve this goal, an integrated view is neces-

sary in which the variability of the software product

is reﬂected in a variable order process. Since only a

few conﬁguration options are usually exposed to the

end-customer, also all internal processes need to be

covered in the variability management process. The

overall concept of the resulting process is highlighted

in Figure 1. As illustrated, the Process Variability

Framework – which was described in Sub-Section 2.2

– is used as a foundation to model variable order pro-

cess models. Based on this order process models,

order entry forms are automatically generated which

need to be ﬁlled by internal or external customers.

Based on the provided data, a product line is triggered

which maps the provided order data to the customiza-

tion options of the software product. Based on the

generated feature mapping, the ﬁnal product can be

automatically derived without any manual step beside

veriﬁcation steps which may be required by certiﬁ-

cation requirements. In order to achieve a binding

between the order process models and the generated

order entry forms, the following type model was in-

troduced (Sinnhofer et al. (2017)):

• None: No special data needs to be submitted.

Thus, a process node marked with none will not

appear as a setting in the order entry form.

• Inputs: This is the abstract concept for differ-

ent input types which are described below. Each

Combined Variability Management of Business Processes and Software Architectures

Order Entry

(e.g. Web-Interface)

Process

Variability

Framework

Customer

Domain Experts

Process Variant

Process

Model

Internal Customer

generated

configures

Maintenance

Evolve

influences

Feature

Model

Feature

Selection

Feature

Transformation

Generators

Product

Domain Experts

verify

Order Data

Figure 1: Overview of the concept for combining order process variability and software variability to automatically derive

software products.

Input is mapped to a speciﬁc input type, deﬁn-

ing the format of the input. For example, input

data could be delivered in form of a ﬁle, or con-

ﬁguration settings could be delivered in form of

strings or integer values. Depending on the ap-

plied domain, also non functional properties may

need to be modeled in the Input type. For exam-

ple, if a security critical product is developed, a

customer may be asked to provide a cryptographic

key which is used to authenticate the customer to

the device. Besides providing this key, also some

kind of speciﬁcation is required in which format

this data was provided (e.g. pgp encrypted, etc).

• Customer Input: Speciﬁc data that has to be

added from an external customer. A process ac-

tivity marked with this type will generate an entry

in the order entry form of a speciﬁc type. For ex-

ample, drop down list will appear if a customer

can select between different options.

• Internal Input: Speciﬁc data needs to be added

from an internal stakeholder. A process activity

marked with this type will not generate an entry

in the external customer order interface, but will

create a separate order entry for the according in-

ternal stakeholder.

• Input Group: A set of inputs which are logically

linked together. As a consequence, all of these

inputs will be highlighted as a group in the gener-

ated order entry and all of them are required for a

single customization feature of the ﬁnal software

product.

The information type has to be added to the pro-

cess feature model of the SPLE tool. To support the

domain experts in creating the according mappings,

the following rules are automatically applied by the

SPLE tool based on the BPMN types (Sinnhofer et al.

(2017)):

• Activities: Non-atomic activities are used to

group speciﬁc sets of input parameter to a single

feature. For example, a process designed for cus-

tomizing an application may require several in-

put parameter (like user name, password, license

ﬁles, etc.). As a consequence, non-atomic activi-

ties will appear as an Input Group for all inputs

deﬁned by the according sub-process(es). Any

atomic activity will be automatically tagged as

input type ”None”. The input type ”None” is

also automatically applied if a non-atomic activity

does not contain any data. Consequently, ”empty”

non-atomic activities will also not appear in the

generated order entry form.

• Gateways: Are used to deﬁne the structure of

the generated form. For example, for a decision

node, a drop down selection will appear such that

the customer can choose between different cus-

tomization paths. For decisions it is further en-

forced that the customer can only select and sub-

mit the data for one single path.

• Data: Data is to be provided by any entity in-

volved in the process(es). With respect to our case

study, ”String” turned out to be a meaningful de-

fault value.

• Pool and Lanes: Are used to deﬁne the source of

the input data. For example, a data node which is

part of a company internal lane will automatically

be tagged as an ”Internal Input”, while Data in an

external lane will be marked as ”External Input”.

”Internal Input” should be used as a default value

to circumvent accidental exposure of internal con-

ﬁguration settings to the end-customer if Pool and

Lanes are not used.

All default mapping rules can be manually over-

written by the Domain Expert during the creation of

the process model. Changes to the process model

Seventh International Symposium on Business Modeling and Software Design

Configure

Web Server

Configure

Web Server

Configure

Encryption

Key

IP Address

IP Address Key

Configure

Web Server

Configure

Encryption

Key

IP Address Encryption Key

Load

Customer

Applications

Binary

Version 1 Version 2

Version 3

Figure 2: Exemplary order processes for the three differ-

ent versions of the IoT device, based on (Sinnhofer et al.

(2017)).

Order Process

Conﬁgure

Web Server

Conﬁgure Data

Protection

Load Customer

Application

IP Address Encryption Key Executable

Mandatory Optional

Requires

Figure 3: Exemplary feature model for the customization

of the IoT device in three different ﬂavors.

(e.g. adding/removing/changing activities) are traced

via unique identiﬁers and illustrated as a diff-model

such that changes can be reviewed by the Domain

Experts. After the order process model was success-

fully tagged, the according order entry forms can be

generated. With respect to this work, we have cho-

sen web-based forms since they are commonly used

in practice.

As illustrated in Figure 1, the provided customer

data is used to create the feature selection of the ﬁnal

product. A manual veriﬁcation step is advisable in or-

der to ensure that no mistake was made during the de-

velopment of the translation logic. Additionally, for

certiﬁcation purposes it may also need to be proven

that a veriﬁcation was done to ensure that no cus-

tomer related data is confused with other products. In

order to automatically select the features, the group-

ing information of the order entry is used to select the

required features. After the selection was approved

by the Domain Experts, it is automatically processed

by the product speciﬁc code generators of the product

line which utilizes the provided order data to actu-

ally generate the according product. The result of this

process strongly depends on the use case: It could be

a binary ﬁle that is loaded to the Integrated Circuits

during the production, a conﬁguration script which is

executed on the ﬁnal product, or any other approach.

We will discuss a script based approach in Section 4

in more detail.

Especially for new types of products it is very

likely that new knowledge is gained on how to in-

crease the efﬁciency of the whole process(es). Only if

changes to the generated order entry forms are nec-

essary, a maintenance process for the product cus-

tomization system is required. The maintenance costs

for the product line can be kept as low as possible,

since the code generators and model transformation

logic only has to be updated once, but can be reused

for the whole product line.

4 INDUSTRIAL CASE STUDY

For illustration purposes, we will discuss our indus-

trial case study in more detail, showing how process

models are translated and the ﬁnal product is auto-

matically derived. The implemented business pro-

cesses of our industrial partner are controlled by an

SAP infrastructure and are designed with the BPM-

Tool Aeneis. Further, we are using the SPLE tool

pure::variants to manage to variability of the business

processes as well as the variability of the ﬁnal prod-

uct conﬁgurations. A more detailed description of the

developed tools plugins can be found in our previous

publications (see Sinnhofer et al. (2015, 2016)). For

illustration purposes, we will consider the following –

simpliﬁed – example: A company is developing small

embedded systems which are used as sensing devices

for the Internet of Things (IoT). The devices are sold

to distributors (refered to as customer in the follow-

ing) in high quantities which mean that the customiza-

tion of the devices cannot be done by the customer

in a feasible way. The device is offered in three dif-

ferent variants with the following features (based on

Sinnhofer et al. (2017)):

Version 1: Senses the data in a given time inter-

val and sends the recorded signal to a customer oper-

ated web-server which is used for post-processing the

data. In the ﬁrst version, the communication channel

between the web-server and the device is unprotected.

The customer is responsible for providing the connec-

tion string of the web-server to the company.

Version 2: Additionally to the basic features of

the ﬁrst version, this version allows encryption of

the communication channel between the server and

the node using symmetric encryption algorithms. For

simplicity of this example, it can be assumed that the

encryption key is provided by the customer, which has

to be loaded to every single device. For simplicity, we

assume that the key is sent in plain by the customer.

Combined Variability Management of Business Processes and Software Architectures

Figure 4: Exemplary order entry form that is automatically

generated from the Feature Model highlighted in Figure 3.

Version 3: Additionally to the basic features of

the ﬁrst version, this version allows customer appli-

cations to be run on the system. This requires that the

customer submits a binary ﬁle which is loaded to the

device during the production.

Traditionally, this would result in three different

order processes which are formed via a copy and

clone strategy (see Figure 2): The order process of

the ﬁrst version is copied and extended for the sec-

ond version, while the third version is an extended

copy of the second version. This means that changes

to the basic version would result in the maintenance

of two other processes as well. Using our developed

framework leads to the situation that all three pro-

cess variants are derived from one common process

model. As such, the same result is achieved like us-

ing a manual preparation, but the maintenance costs

can be reduced essentially since all variants are au-

tomatically updated. The according Feature Model

is illustrated in Figure 3. For illustration purposes, a

”requires” relationship between the web-server con-

ﬁguration and the data protection conﬁguration is not

highlighted since the ”Conﬁgure Web Server” feature

is a mandatory feature. Consequently, the conﬁgura-

tion is always part of the ﬁnal product and does not

need to be explicitly modeled.

To automatically generate the order entry form

based on the feature model, the input data ”IP Ad-

dress”, ”Encryption Key”, and ”Binary” has to be set

to the according type. As such, rules can be deﬁned

to ensure that the given IP Address is formatted as

a valid IPv4 or IPv6 IP Address, or that the encryp-

tion key has a meaningful length, etc. If no additional

checks are implemented, the Domain Expert would

only need to specify the input type of the ”Binary” to

be a binary ﬁle. Doing so, the order entry form illus-

trated in Figure 4 can be generated, assuming that all

input parameter are provided by the customer. After

FDL Interpreter

Submission

File

Config

Script

Function Description Language

Language

Primitives

Operations

Script

References

Implementation

Abstract Class

Hierarchy

generated

Figure 5: Framework for a ﬂexible, runtime-conﬁgurable

script generation system.

clicking the submit button on the order entry form,

the provided data is converted into an XML ﬁle and

zipped together with all the provided ﬁles to a zip

archive. The XML ﬁle is necessary to ensure that the

product conﬁguration product line is able to automat-

ically interpret the given zip ﬁle. Further, having an

XML ﬁle has also the positive side effect that it is

human readable which is essential for manual veri-

ﬁcation steps. Additional data can be included into

the archive like identiﬁers and time-stamps to have a

traceable link from placing an order to the actual man-

ufacturing of the product.

Based on the provided data, the ﬁnal product can

be generated using dedicated code generators. To al-

low a ﬂexible system without the need of re-releasing

the product line if new products are supported, we

decided to deﬁne run-time conﬁgurable generators.

For this purpose we deﬁned a Domain Speciﬁc Lan-

guage (DSL) which is designed to be used by prod-

uct experts. This DSL is called Function Description

Language (FDL) and is used to create customization

scripts for the ﬁnal product. This means that during

the production process, a script is loaded to each de-

vice which is triggered automatically to customize the

according devices. For every supported product fam-

ily, a Function Description (FD) is written which basi-

cally lists all the possible features of the platform (i.e.

the customization options of the order process model)

and how the provided order data is translated into the

ﬁnal script. The overall concept is illustrated in Fig-

ure 5. A script library is used which contains common

scripts that can be referenced by the function descrip-

tion. For example, a ’loadApplication’ script may be

developed for the product line in order to install the

customer provided application to the devices.

5 EVALUATION

First results were already compiled in our previous

works (Sinnhofer et al. (2016, 2017)) in which we

compared the development efforts using ”traditional

Seventh International Symposium on Business Modeling and Software Design

software development” techniques and compared it

with the overhead of the developed framework. We

use the term ”traditional software development” tech-

niques for a software development with ad-hoc (or

near to ad-hoc) software architecture which means

that multiple different systems are designed almost

independent, but make use of copy and adapt strate-

gies. Consequently, the maintenance efforts for such

systems are rather high. We investigated, that the eco-

nomical breakeven point of the developed framework

is at around 3 to 4 systems. Further, the robustness

of the customization process was increased since au-

tomatic methods were used for the feature selection

and thus, conﬁguration errors could be reduced sig-

niﬁcantly. Through the use of automatic methods, it

was also possible to generate log-ﬁles for certiﬁcation

purposes which are used to ensure that the provided

customer data was loaded and not confused or manip-

ulated.

In this work, we will investigate other aspects of

5 10 15 20 25 30

100

Customization Options

Number of Products

Number of orders

Quantitative costs

5 10 15 20 25 30

Customization Options

Quantitative Revenue

Figure 6: Analysis of the development efforts and revenue

to identify business drivers. The revenue and the costs are

illustrated in a quantitative manner.

the developed framework, namely the identiﬁcation

of business drivers: We analyzed the development

efforts of individual product features and contrasted

them with the revenue that was earned by selling the

according product conﬁguration. The development

efforts were extracted from the time-recordings of the

responsible workers and should give a reasonable esti-

mate about the real development efforts. In total, 106

different product orders were analyzed which pro-

vided 30 individual conﬁguration settings. The re-

sults are illustrated in Figure 6. The ﬁrst 10 prod-

uct conﬁguration options are internal system speciﬁc

conﬁguration settings which are mandatory for every

product. A business decision was taken to reduce the

costs for the base system to a minimum level to en-

sure a low cost base product. As a consequence, the

revenue earned by the basic product conﬁguration is

rather low compared to other customization options.

An interesting ﬁnding was that a lot of development

effort was invested in complex features which were

never used for any customer or are only rarely used.

Due to this ﬁnding, it was decided that some of the

features will be removed from the product in a future

release, in order to reduce the overall costs. As illus-

trated in the Figure, feature 12 required a lot of devel-

opment effort, but is also frequently ordered by cus-

tomers. Consequently, an improvement process was

triggered in order to reduce the costs of this feature.

After having discussed the positive aspects of the

developed framework, we also want to address some

limitations of the current implementation: While we

were able to fully generate the required customization

scripts for simple product conﬁgurations, we were

able to only partially generate the scripts for com-

plex product conﬁgurations due to the high number of

inter-feature constraints of the product features. This

is not a technical problem of the approach, but having

a complete coverage of all inter-feature constraints

is a time-consuming and iterative process. Further,

modeling all the constraints in advance is usually not

possible for complex systems. As a result, we decided

to model only basic constraints in advance and to up-

date the constraint model with every product order.

Based on this semi-automatic generation, we man-

aged to reduce the time to release a complex product

by 50 percent.

6 RELATED WORK

Traditionally, business process modeling languages

do not explicitely support the representation of fam-

ilies of process variants (Rosa et al. (2017)). As a

consequence, a lot of work can be found which tries

Combined Variability Management of Business Processes and Software Architectures

to extend traditional process modeling languages with

notations to build adaptable process models. As such,

adaptable process models can be customized accord-

ing to domain requirements by adding or removing

fragments to the model and by explicitly transform-

ing this model to dedicated process variants which can

be executed in the ﬁeld. This promises to increase

the ﬂexibility of business process oriented organiza-

tions with respect to highly ﬂexible requirements of

the market. Having such a variability modeling for

business process models builds the foundation of this

work. Thus, related work which is utilizing similar

modeling concepts are presented in the following:

Derguech (2010) presents a framework for the

systematic reuse of process models. In contrast to this

work, it captures the variability of the process model

at the business goal level and describes how to inte-

grate new goals/sub-goals into the existing data struc-

ture. The variability of the process is not addressed in

his work.

Gimenes et al. (2008) presents a feature based

approach to support e-contract negotiation based on

web-services (WS). A meta-model for WS-contract

representation is given and a way is shown how to in-

tegrate the variability of these contracts into the busi-

ness processes to enable process automation. It does

not address the variability of the process itself but en-

ables the ability to reuse business processes for differ-

ent e-contract negotiations.

While our used framework to model process vari-

ability reduces the overall process complexity by

splitting up the process into layers with increas-

ing details, the PROVOP project (Hallerbach et al.

(2009a,b) and Reichert et al. (2014)) focuses on the

concept, that variants are derived from a basic pro-

cess deﬁnition through well-deﬁned change opera-

tions (ranging from the deletion, addition, moving of

model elements or the adaptation of an element at-

tribute). In fact, the basic process expresses all pos-

sible variants at once, leading to a big process model.

Their approach could be beneﬁcial considering that

cross functional requirements can be located in a sin-

gle process description, but having one huge process

is also contra productive (e.g. the exchange of parts

of the process is difﬁcult).

The work of Gottschalk et al. (2007) presents an

approach for the automated conﬁguration of work-

ﬂow models within a workﬂow modelling language.

The term workﬂow model is used for the speciﬁca-

tion of a business process which enables the execution

in an enterprise and workﬂow management system.

The approach focuses on the activation or deactiva-

tion of actions and thus is comparable to the PROVOP

project for the workﬂow model domain.

Rosa et al. (2008) extend the conﬁgurable process

modelling notation developed from Gottschalk et al.

(2007) with notions of roles and objects providing a

way to address not only the variability of the control-

ﬂow of a workﬂow model but also of the related re-

sources and responsibilities.

The Common Variability Language (CVL Haugen

et al. (2013)) is a language for specifying and resolv-

ing variability independent from the domain of the ap-

plication. It facilitates the speciﬁcation and resolution

of variability over any instance of any language de-

ﬁned using a MOF-based meta-model. A CVL based

variability modelling and a BPM model with an ap-

propriate model transformation could lead to similar

results as presented in this paper.

The work of Zhao and Zou (2011) shows a frame-

work for the generation of software modules based on

business processes. They use clustering algorithms

to analyse dependencies among data and tasks, cap-

tured in business processes. Further, they group the

strongly dependent tasks and data into a software

component.

7 CONCLUSION

The reuse of business process models is an important

step for process driven organizations to survive in a

competitive market. Through an integrated view of

the according IT, it is possible to raise the efﬁciency

of the overall business. With this and our previous

works, we proposed a way to use software product

line engineering techniques for the modeling of busi-

ness process models. Further, we developed a frame-

work which enables to combine the variability models

of order processes with the variability models of soft-

ware customization product lines. This enables an au-

tomatic customization process which is triggered by

the according order processes. As a result, the devel-

opment costs and the required time to react to changes

of the market can be reduced signiﬁcantly. Moreover,

using the proposed techniques supports Domain Ex-

perts to identify business drivers and thus, raise the

overall efﬁciency of the organization.

In the current state, the presented framework is fo-

cused on covering the variability of order processes

for similar type of products. Consequently, future

work will address the extension of the developed

framework to other processes. Further, we are cur-

rently investigating methods on how to bind non-

functional requirements like security requirements to

the variability models in order to enforce speciﬁc

properties throughout the whole process in an auto-

matic and systematic way.

Seventh International Symposium on Business Modeling and Software Design

ACKNOWLEDGEMENTS

The project is funded by the Austrian Research Pro-

motion Agency (FFG). We want to gratefully thank

Danilo Beuche from pure::systems for his support.

REFERENCES

Association of Business Process Management Profession-

als (2009). Guide to the Business Process Manage-

ment Common Body of Knowledge: ABPMP BPM

CBOK

. Association of Business Process Manage-

ment Professionals.

Derguech, W. (2010). Towards a Framework for Business

Process Models Reuse. In The CAiSE Doctoral Con-

sortium.

Gimenes, I., Fantinato, M., and Toledo, M. (2008). A Prod-

uct Line for Business Process Management. Software

Product Line Conference, International, pages 265–

274.

Gottschalk, F., van der Aalst, W. M. P., Jansen-Vullers,

M. H., and Rosa, M. L. (2007). Conﬁgurable Work-

ﬂow Models. International Journal of Cooperative

Information Systems.

Hallerbach, A., Bauer, T., and Reichert, M. (2009a). Guar-

anteeing Soundness of Conﬁgurable Process Variants

in Provop. In Commerce and Enterprise Computing,

2009. CEC ’09. IEEE Conference on, pages 98–105.

IEEE.

Hallerbach, A., Bauer, T., and Reichert, M. (2009b). Issues

in modeling process variants with Provop. In Ardagna,

D., Mecella, M., and Yang, J., editors, Business Pro-

cess Management Workshops, volume 17 of Lecture

Notes in Business Information Processing, pages 56–

67. Springer Berlin Heidelberg.

Hammer, M. and Champy, J. (1993). Reengineering the

Corporation - A Manifesto For Business Revolution.

Harper Business.

Haugen, O., Wasowski, A., and Czarnecki, K. (2013). Cvl:

Common variability language. In Proceedings of the

17th International Software Product Line Conference,

SPLC ’13.

Kang, K. C., Cohen, S. G., Hess, J. A., Novak, W. E.,

and Peterson, A. S. (1990). Feature-oriented domain

analysis (foda) feasibility study. Technical report,

Carnegie-Mellon University Software Engineering In-

stitute.

McCormack, K. P. and Johnson, W. C. (2000). Business

Process Orientation: Gaining the E-Business Com-

petitive Advantage. Saint Lucie Press.

Object Management Group, O. (2011). Business process

model and notation (bpmn). version 2.0. pages 1–538.

available at http://www.omg.org/spec/BPMN/2.0/.

Osterle, H. (1995). Business Engineering - Prozess- und

Systementwicklung. Springer-Verlag.

Pohl, K., B

ockle, G., and Linden, F. J. v. d. (2005). Soft-

ware Product Line Engineering: Foundations, Princi-

ples and Techniques. Springer-Verlag New York, Inc.,

Secaucus, NJ, USA.

Reichert, M., Hallerbach, A., and Bauer, T. (2014). Lifecy-

cle Support for Business Process Variants. In Jan vom

Brocke and Michael Rosemann, editor, Handbook on

Business Process Management 1. Springer.

Rosa, M. L., Aalst, W. M. P. V. D., Dumas, M., and Milani,

F. P. (2017). Business process variability modeling: A

survey. ACM Comput. Surv., 50(1):2:1–2:45.

Rosa, M. L., Dumas, M., ter Hofstede, A. H. M., Mendling,

J., and Gottschalk, F. (2008). Beyond control-ﬂow:

Extending business process conﬁguration to roles and

objects. In Li, Q., Spaccapietra, S., and Yu, E., editors,

27th International Conference on Conceptual Mod-

eling (ER 2008), pages 199–215, Barcelona, Spain.

Springer.

Saidani, O. and Nurcan, S. (2007). Towards context aware

business process modelling. In 8th Workshop on Busi-

ness Process Modeling, Development, and Support

(BPMDS07), CAiSE, volume 7, page 1.

Sinnhofer, A. D., P

uhringer, P., and Kreiner, C. (2015).

varbpm - a product line for creating business process

model variants. In Proceedings of the Fifth Interna-

tional Symposium on Business Modeling and Software

Design - Volume 1: BMSD,, pages 184–191.

Sinnhofer, A. D., P

uhringer, P., Potzmader, K., Orthacker,

C., Steger, C., and Kreiner, C. (2016). A framework

for process driven software conﬁguration. In Proceed-

ings of the Sixth International Symposium on Business

Modeling and Software Design - Volume 1: BMSD,,

pages 196–203.

Sinnhofer, A. D., P

uhringer, P., Potzmader, K., Orthacker,

C., Steger, C., and Kreiner, C. (2017). Software Con-

ﬁguration Based on Order Processes, pages 200–220.

Springer International Publishing, Cham.

Strnadl, C. F. (2006). Aligning business and it: The process-

driven architecture model. Information Systems Man-

agement, 23(4):67–77.

Valena, G., Alves, C., Alves, V., and Niu, N. (2013). A

Systematic Mapping Study on Business Process Vari-

ability. International Journal of Computer Science &

Information Technology (IJCSIT).

Weiss, D. M. and Lai, C. T. R. (1999). Software Product-

line Engineering: A Family-based Software Develop-

ment Process. Addison-Wesley Longman Publishing

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

Willaert, P., Van Den Bergh, J., Willems, J., and De-

schoolmeester, D. (2007). The Process-Oriented Or-

ganisation: A Holistic View - Developing a Frame-

work for Business Process Orientation Maturity.

Springer.

Zhao, X. and Zou, Y. (2011). A business process-driven

approach for generating software modules. Software:

Practice and Experience, 41(10):1049–1071.

Combined Variability Management of Business Processes and Software Architectures