A M ETHODOLOGY F RAGMENT FOR
D EVELOPING FAMILIES OF B USINESS
I NFORMATION S YSTEMS
I MPROVING THE D ESIGN OF B USINESS FAMILIES FOR
S ERVICE O RIENTED A RCHITECTURES
I LDEFONSO M ONTERO P ÉREZ
M ARCH 17, 2009
A Methodology Fragment for Developing
Families of Business Information Systems
Improving the Design of Business Families for Service Oriented
Ildefonso Montero Pérez, 75760309-B
Supervised by Prof. Dr. Joaquin Peña
and Prof. Dr. Antonio Ruiz-Cortés
Thesis project submitted to the Department of Computer Languages
and Systems of the University of Sevilla in partial fulﬁlment
of the requirements for the degree of Ph.D. in Computer Engineering.
Support: This work has been partially supported by the European
Commission (FEDER) and Spanish Government under CICYT project Web-
Factories (TIN2006-00472) and by the Andalusian Government under project
This research report has been developed regarding the instructions laid
in Chapter I, Article 5, Paragraph 2, of the Doctorate Regulations from the
University of Seville. This work implies an estimated effort about 360 hours
(12 credits) and it was developed using the structure proposed in the cited
Now that this research report comes to an end, it is time to express my
gratitude to the people who have supported me along this path that I has just
started. First of all, I would like to thank to my family and friends for their
support when it was so necessary. Thus, I would like to thank to Lucia, for her
endless patience and love.
In addition, I would like to thank my research advisors, Joaquin and Anto-
nio, for their help and support into my research career.
Finally, I would like also to thank to all my industry and academic col-
leagues, whose comments and suggestions improved the contents and pre-
sentation of this research report substantially.
Service Oriented Architectures (SOA) is a change in the approach for de-
veloping solutions and moving from create programs that perform a func-
tion for the end user, to think, design and develop interoperable services that
model our business and allow us to build applications by composing func-
tional parts. In this context, a new paradigm named Business-Driven Devel-
opment (BDD) has been arised, in order to provide techniques and methods
to support the analysis, design and implementation of the business processes
of a company, as interoperable behavioural interfaces which can be deployed
as independent services into an Enterprise Service Bus (ESB) infrastructure.
Current speciﬁcations for designing business processes by means of mod-
elling techniques and notations, such as Business Process Modeling Notation
(BPMN), provides support for the activities deﬁned into the BDD paradigm.
However, the variability level of average-size Business Information Systems
(BIS) is usually highly enough for making the design of this kind of systems
a complex task. In addition, is a fact that there exists several companies that
shares common business processes, and maximize the level of reuse of their
deﬁnitions is considered a core need.
Thus, our research hypothesis states that the reuse across businesses by
means of Software Product Line (SPL) techniques can be exploited. It means
that is feasible the deﬁnition of Business Families. For that purpose, our re-
search is focused on providing reference models and technologies that are
necessary to help companies bridge the gap of dealing with variability on the
design of BIS and to increase the reusability of their business process deﬁni-
In this report, we give an overview of the current state of art of our research
context. Results from this analysis motivate our research work, which has
been already materialized in several contributions and has been presented in
the research report too.
Las Arquitecturas Orientadas a Servicios (SOA) suponen un cambio en el
enfoque para el desarrollo de soluciones y dar el paso de crear programas
que realizan una función concreta para el usuario ﬁnal, a pensar, diseñar y
desarrollar servicios interoperables que modelan nuestro negocio y nos per-
miten construir aplicaciones componiendo piezas funcionales. En este contex-
to, un nuevo paradigma llamado Desarrollo Guiado por el Negocio (BDD), ha
aparecido recientemente con el ﬁn de proporcionar técnicas y métodos para
dar soporte al análisis, diseño e implementación de los procesos empresar-
iales de una empresa, proporcionando interfaces interoperables de compor-
tamiento que pueden ser desplegadas como servicios independientes en una
infraestructura basada en un Bus Empresarial de Servicios (ESB).
Las especiﬁcaciones actuales para el diseño de procesos de negocio por
medio de técnicas de modelización y anotaciones, como Business Process
Modeling Notation (BPMN), prestan apoyo a las actividades deﬁnidas en el
paradigma BDD. Sin embargo, la variabilidad implicita en Sistemas de Infor-
macion de Negocio (BIS) de granularidad gruesa es por lo general mas que
suﬁciente para que el diseño de este tipo de sistemas se considere una tarea
compleja. Además, es un hecho que pueden existir varias empresas que com-
partan procesos de negocio similares, y maximizar el nivel de reutilización de
sus deﬁniciones se considera una necesidad básica.
Por lo tanto, nuestra hipótesis de investigación sostiene que la reuti-
lización, a través de tecnicas del campo de las Lineas de Productos Software
(SPL), puede ser explotada. Esto signiﬁca que es posible la deﬁnición de Famil-
ias de Negocio. A tal efecto, nuestra investigación se centra en proporcionar
modelos de referencia y tecnologías necesarias para ayudar a las empresas a
superar la brecha de hacer frente a la variabilidad en el diseño de Sistemas de
Informacion de Negocio y para aumentar la reutilización las deﬁniciones de
los procesos. En este informe, proporcionamos una visión general del actual
estado del arte de nuestro contexto de la investigación. Los resultados de este
análisis motivan nuestros trabajos de investigación, que ya se ha materializa-
do en varias contribuciones y son presentados tambien en este informe.
O n the one hand, the development of Business Information Systems
(BIS) is focused on providing techniques and mechanisms for de-
signing software systems based on the business processes of the companies,
deﬁned graphically by means of modeling notations, such as Business Process
Model Notation (BPMN) .
On the other hand, the Software Product Lines (SPL) ﬁeld systematizes the
reuse across the set of similar products that a software company produces. It
implies a reduction of development times and costs and a quality improve-
In order to increase the process deﬁnitions reusability, we propose a
methodology based on applying SPL ideas for the systematization of the de-
velopment of BIS across a several number of businesses that shares common
business processes. Thus, the contribution of this work is to deﬁne and explore
the feasibility and beneﬁts of what we call Business Family Engineering.
In this chapter, we introduce ﬁrst the motivation of our research work in
Sections §1.1 and §1.2; the research context in Section §1.3; we enunciate our
research methodology in Section §1.5 and our hypothesis and several research
questions in Section §1.4; and ﬁnally, we describe the goals and structure of
this research report in Section §1.6.
4 Chapter 1. Introduction
The variability level of average-size Business Information Systems (BIS) is
usually highly enough for making the design of this kind of systems a complex
task. In addition, is a fact that there exists several companies that shares com-
mon business processes, and maximize the level of reuse of their deﬁnitions is
considered a core need.
For that purpose, there is an approach, called Process Family Engineer-
ing (PFE)  (See Section §1.3.3 for more details), that tries to increase the
reusability on the development of BIS using ideas from the Software Product
Lines (SPL) ﬁeld . Roughly speaking, the SPL ﬁeld systematizes the reuse
across the set of similar products that a software company provides. For that
purpose, this approach requires to describe the products by means of vari-
ability models, such as Feature Models (FM), that contains only features and
relationships between them. A feature is considered as a characteristic of the
system that is observable by the end users. Feature Models describe which
features are present in all the products, called core features, and which not,
called variable features. (See Section §1.3.2 for a more detailed description).
In addition, the PFE approach identiﬁes some variability aspects on busi-
ness process models, and proposes to extending the standard BPMN for rep-
resenting it . However, although the PFE approach is quite valuable, it
presents some drawbacks related with ambiguity and maintenance that are
described at Section §1.3.3.
Thus, the main motivation of this research is to provide a methodology
that taking into account the PFE drawbacks makes feasible the possibility of
develop families of business information systems. For that purpose, as shown
in Chapter §4, we provide a methodology named Business Family Engineer-
ing, we deﬁne the fragment of this methodology focused on obtaining the
core architecture of the family, namely Business Family Domain Engineering
in Chapter §5, and we explore its feasibility on modeling choreographies in
Chapter §6. These topics are the focus of our research. In addition, we moti-
vate our approach by means of a real-life case study deﬁned in the Web Ser-
vice Choreography Interface (WSCI) speciﬁcation . Finally, as proof of
concepts, we have developed an Eclipse tool that provides support for one of
the activities of this methodology fragment. See Chapter §7 for more details
about tool support.
As a result of our contributions, we improve the development of business
information systems reducing its complexity level in situations where is nec-
essary to perform a business family, using our proposed methodology. In ad-
1.2. Motivating our research with a WSCI example 5
dition, since to one of the topics of our approach is focused on providing the
core architecture of the family, we provide to process engineers some artifacts
for improving their activities, such as a business family variability summary
and a core process framework (See Chapter §5 for a more detailed descrip-
tion). This artifacts provides a basic structure of the business process model
that supports the variability aspects identiﬁed by the PFE approach, without
the need of extending the standard notation of BPMN.
1.2 Motivating our research with a WSCI example
The Web Service Choreography Interface (WSCI) speciﬁcation  pro-
vides a comprehensive example that illustrates how to model a scenario that
reﬂects the real life business process of reserving and booking airline tickets.
A derivation of this example, for deﬁning an hotel booking process has been
used for illustrating the Process Family Engineering (PFE) approach in .
See Section §1.3.3 for more details about the PFE approach. We use the WSCI
case study as starting point for deﬁning how to develop families of business
information systems that provides support for any booking process.
The scenario provided by the WSCI speciﬁcation is the following: there ex-
ists three different participants involved into the reserving and booking airline
tickets business process, concretely a Traveler, a Travel Agent, and an Airline
Reservation System. Each participant collaborate in the overall process called
Plan&Book, as shown in Figure §1.1. This business process is composed by
the following subprocesses: (i) Order Trip : it deﬁnes the steps needed for
performing the submission of the preferred trip plan from the Traveler to the
Travel Agent, who evaluates the preferences, and send a possible itinerary to
the Traveler. It is performed by means of a collaboration between the Travel
Agent and the Airline Reservation System by means of a business process
named Verify Seats Availability. This business process is a subprocess of Or-
der Trip ; (ii) Cancel Itinerary : it deﬁnes the steps needed for canceling the
provided itinerary from the Travel Agent; (iii) Change Itinerary : it deﬁnes
the steps needed for performing a submission from the Traveler to the Travel
Agent to change the proposed itinerary; and (iv) Reserve Tickets : it deﬁnes
the steps needed for reserving the trip related with the proposed itinerary.
This business process is decomposed by four subprocesses: Book Tickets, Book
Seats (that needs a previous reservation step for the seats performed by other
business process named Reserve Seats ), Send Tickets and ﬁnally, Send State-
ment. This case study provides a complete real life example of reserving and
booking a trip for any possible airline travel agency. We are going to sup-
pose that several airline travel agencies, such as Iberia, Ryanair, etc. performs
6 Chapter 1. Introduction
I want to travel to Ulm
Traveler Travel Agent
Figure 1.1: Case study scenario.
this business process. In other words, these travel agencies share the common
business process of Plan&Book. In addition, is feasible that these companies
share other set of business processes, and also, performs a set of speciﬁc pro-
cesses from each company.
Taking into account the previous consideration, we are going to extend the
WSCI case study providing speciﬁc business processes from any possible air-
line travel agency. Thus, we introduce the following business processes: (i)
Inform : it deﬁnes the steps needed to provide to the Traveler and to the Travel
Agent the information about ﬂights (delays, connections, etc.) obtained from
an Airline Trafﬁc Control System (we have introduced a new participant in
addition); and (ii) Extras : it deﬁnes the steps needed to provide to the Trav-
eler the information related with some extra services from an airline agency.
In this case study, we have decomposed this business process into two sub-
processes named: Restaurant and Travel Card, that deﬁne the restaurant on
ﬂy subprocess and the management of travel cards respectively.
Once the scenario is deﬁned, we have analyzed the feasibility of develop
a family of airline travel agencies using our approach: Business Family Engi-
neering (BFE). Our research motivation address into the following issues, that
are covered in this report:
1.3. Research Context 7
• Increasing the business process deﬁnitions reusability for each business
information system that provides support for any airline travel agency.
Current process engineers redesign each business information system
using ad hoc techniques to maximize the level of reuse from one product
to another. Our approach states that many common business processes
can be found, and reuse across businesses by means of Software Prod-
uct Line (SPL) techniques can be exploited. See Section §1.3.2 for more
information about the SPL ﬁeld.
• Improving the design of highly variable business process models, also
named variant-rich processes, obtaining the basic structure of the busi-
ness process (that needs to be completed manually). Nowadays, the de-
sign of highly variable business process models is performed extending
the notation of the business process diagram, for example Business Pro-
cess Model Notation (BPMN). It is deﬁned by the PFE approach, that is
detailed in Section §1.3.3
• Visualizing the variability of the business information system. Our ap-
proach states that providing a variability summary is feasible and it
would helps to process engineers to identify the core and variable as-
sets of the family.
1.3 Research Context
In order to clarify the context of this research, in this section we provide a
set of deﬁnitions and considerations about (i) Business Process Management
(BPM), concretely about designing Business Information Systems (BIS), mod-
eling speciﬁcations, and choreography models; (ii) the Software Product Line
(SPL) ﬁeld; and (iii) the Process Family Engineering (PFE) approach.
1.3.1 Business Process Management
Weske deﬁne in  that Business Process Management (BPM) is based on
the observation that each product that a company provides to the market is
the outcome of a number of activities performed. Thus, a ﬁrst step for deﬁn-
ing a Business Process (BP) could be that a BP is considered as a set of these
activities. In addition, Brown establish, in , as a core need that a company
must be able to manage what is called the 3-K :
8 Chapter 1. Introduction
• Know what you got, roughly speaking, the services that the company
provides to the market, also named business goals;
• Know who is doing what, in other words, the set of business partners
that performs several business processes in the company;
• and Know when things change and what it means, which means that the
business processes of the company must deal with the implicit variabil-
ity of the market, since to companies must adapt to continuous market
Taking into account these considerations, a Business Process (BP) is de-
ﬁned as a set of well known activities of a company, performed by a set of
business partners (may own the company or not), for realizing a business goal.
In addition, the deﬁnition of speciﬁcic business processes must be able to be
adapted when company changes. Business Process Management provides the
techniques and methods to support the analysis, design and implementation
of business processes.
Is a fact that most companies, in whichever ﬁeld, have a software system
that helps managing all the aspects of the company. Consequently, the Infor-
mation Technology (IT) infrastructure that supports it must provide support
for the techniques and methods deﬁned in BPM. Thus, a new kind of soft-
ware system is deﬁned: Business Information Systems (BIS). A BIS is a soft-
ware system which is based on a business process design, usually a model
speciﬁcation, that is deployed into a process engine that executes it. Thus,
the Business-Driven Development (BDD) ﬁeld is focused on providing tech-
niques and mechanisms for deﬁning the development of Business Information
Our research work is focused on improving the design of Business Infor-
mation Systems when reuse across several businesses can be exploited. Thus,
our main research context is the Business-Driven Development (BDD) ﬁeld.
Once the main research context is deﬁned, we explore the set of models
needed for designing a BIS: (i) a business process diagram, which deﬁnes
a business process by means of several notations, such as Business Process
Model Notation (BPMN), that is deﬁned in the following subsection; and (ii)
a choreography and collaboration models, deﬁned in Section §220.127.116.11.
1.3. Research Context 9
18.104.22.168 Business Process Modeling and BPMN
Business Process Models are expressed in Business Process Diagrams.
Each business process diagram consists of a set of modeling elements. These
elements allow expressing business processes and are easy to comprehend, so
that process designers can use them without extensive training. Several nota-
tions are introduced for deﬁning business process diagrams, such as Business
Process Modeling Notation (BPMN) , Petri-net based process modeling
languages , UML activity diagrams  or event-driven process chains .
While these modeling languages focus on different levels of abstraction,
ranging from a business level to a more technical level, BPMN aims at sup-
porting the complete range of abstraction levels, including business levels and
software technology levels. Thus, our research is focused on this notation, but
it also can be translated to other one.
Business Process Model Notation (BPMN) is deﬁned by the Object Man-
agement Group (OMG) in  as a ﬂow chart based notation for deﬁning
business processes. BPMN provides (i) a graphical notation based on Business
Process Diagram (BPD); and (ii) a formal mapping to an execution language:
Business Process Execution Language (BPEL). Figure §1.2 depicts the subset
of the most commonly used BPMN elements. These elements can be grouped
by the following categories:
• Swimlanes: a set of symbols that allows us to organize the model. This
set contains the elements named Pool and Lane, as shown in Figure
§1.2.a. A pool represents a participant in a process and acts as a con-
tainer of elements. A lane represents a sub-partition of a pool and are
used to organize and categorize activities.
• Flow objects: a set of symbols that represents the core elements of a busi-
ness process model. Usually this elements are contained in a swimlane.
This set contains the elements named Task, Event and Gateway. Figure
§1.2.b show these elements. A task, also called activity or sub-process, is
the basic element of a work in an organization, it can be atomic or non-
atomic. Event is something that happens in our process that ﬁres the
execution of one or more activities. There exists a lot of events grouped
by: start, intermediate or end event, as for example message events, as
shown in ﬁgure. A gateway is used to control the divergence or con-
vergence of ﬂows as logic doors. In our research we focus on three dif-
ferent gateways: (i) And : which deﬁnes that all the subprocesses con-
trolled by this gateway must be completed for performing a task, (ii)
Xor : which deﬁnes that only one subprocess controlled by this gateway
10 Chapter 1. Introduction
A1 A2 A Sequence
Sub-Process Start Intermediate End Message
Start Intermediate End Flow
(C) Connection Objects
Expanded Sub-Process Events
Gateway Gateway Group
Collapsed Sub-Process XOR
Tasks Artifact /
Lane Gateway Gateway
AND OR Comment /
(A) Swimlanes (B) Flow Objects (D) Artifacts
Figure 1.2: Business Process Model Notation subset.
must be completed for performing a task, and (iii) Or : which deﬁnes that
almost one subprocess controlled by this gateway must be completed for
performing a task. The speciﬁcation of BPMN does not provide any con-
straint about the order of performing this subprocesses in this situations,
it can be done as a sequence or parallel.
• Connection objects: a set of symbols that represents the connections be-
tween the rest of objects in the model. It often represents the messages
between two objects from different swimlanes. Figure §1.2.c depicts this
set, which contains the elements named ﬂows such as, sequences, asso-
ciations and messages.
• Artifacts: a set of additional elements that represents information about
the model or output artifacts of a process represented in it. This elements
are very useful to represent additional information to the reader of the
BPMN, as group, comments or artifacts, also named, data objects gen-
erated or consumed by a business process. Figure §1.2.d. show these
Although BPMN is a graph-based model, it can be deﬁned by mathemat-
ical and theoretical foundations and formalisms, such as CSP , Petri-nets
1.3. Research Context 11
 or Pi -Calculus . Concretely, in our research we explore the capability
of BPMN for implementing ﬁnite state machine representations.
However, although BPMN is a good choice for modeling business pro-
cesses, there exists a several number of proposals which provides very inter-
esting additional elements or extensions to the standard notation [6, 49]. Our
research explore the feasibility of the current BPMN speciﬁcation for provid-
ing support for variability aspects into the design of business families and the
drawbacks of extending the standard notation.
22.214.171.124 Choreography Models
In the Business Driven-Development (BDD) ﬁeld, and specially in Service-
Oriented Computing (SOC), choreography models are acquiring a special im-
portance. A choreography lists all possible interactions between a set of busi-
ness partners, together with the behavioral constraints between them .
Choreography models represents the observable behavior of business part-
ners deﬁned by means of interaction contracts. Several industry initiatives are
in place for establishing standarized choreographies in particular domains,
such as Health Level Seven (HL7) for heath care services †1 .
Process choreographies describe the interaction of multiple business pro-
cesses and, as such, are an important concept for supporting business-to-
business collaboration. Thus, modeling choreographies is considered a core
need for designing Business Information Systems. The activities needed for
develop a choreography model are described as follows:
• High-level Structure Design: in this activity the participant roles as well
as their communication structures are identiﬁed.
• High-level Behavioral Design: this activity is focused on specifying the
goals, also named milestones, of the collaboration and the order in which
the goals are reached.
• Collaboration Scenarios: in this activity the high-level choreographies
are reﬁned by introducing dedicated collaboration scenarios that relate
the reaching of goals to the communication between process partici-
• Behavioral Interfaces: from these collaboration scenarios, for each par-
ticipant role, a behavioral interface is derived in this activity.
1.3. Research Context 13
In addition, current proposals for modeling choreographies does not pro-
vide any support for introducing variability aspects into the design of busi-
ness families. Thus, other contribution of this research work is two-fold. In
the one hand, we propose a choreography model based on an UML2 pro-
ﬁle used on Agent-Oriented Software Engineering (AOSE) ﬁeld that makes
feasible the variability support; and in the other hand we provide a transfor-
mation between this choreography model and BPMN elements for improving
the design of what we call business families, by means of the Business Family
Engineering approach without extending the current notation of BPMN.
1.3.2 Software Product Lines and Feature Models
Pohl et al. deﬁne in [27, 46] that Software Product Line (SPL) develop-
ment aims at and achieves pro-active, constructive reuse, based on the idea
to develop software products which share a signiﬁcant amount of character-
istics, namely features. Thus, a feature is a characteristic of the system that
is observable by the end user. Roughly speaking, SPL systematizes the reuse
across the set of similar products, deﬁned by means of their features, that a
software company provides.
The SPL approach is devoted to overcome complexity providing all the
techniques needed for enabling the mass production of software in a certain
application domain. The variability concept appears in SPL to represent the
differences and commonalities inside an application domain. Variability is
one of the critical aspects of SPL and it must be managed at all the stages of
SPL development. Thus, the software process of SPL is divided into two main
stages: Domain Engineering, which is in charge of providing the reusable core
assets that are exploited during the derivation of products, done at a second
stage named Application Engineering .
One of the most accepted techniques to represent the set of products of
an SPL are Feature Models (FM) . The main goal of feature modeling is
to identify commonalities and differences among all products of an SPL. A
feature model is a compact representation of all potential products of an SPL
showing a set of features in an hierarchical structure where it is shown which
features are present in a product of the product line. Figure §1.4 shows the
feature model of our case study. A FM establishes a parental relationship be-
tween each feature, as shown in Figure §1.4, that can be:
• Mandatory: if a child feature node is deﬁned as mandatory, it must be
included in every product that contains the parent;
14 Chapter 1. Introduction
A Change Reserve Cancel
Inform Extras Order Trip
Itinerary Tickets Itinerary
B1 B2 B3
relation Travel Verify Seats Book Reserve Send Send
Card Availability Tickets Seats Tickets Statement
B1 B2 B3
Figure 1.4: Feature Model of our case study.
• Optional: if a child feature node is deﬁned as optional, it can be included
or not when its father feature appears in a product;
• Alternative: if the relationship between a set of children nodes and their
father is deﬁned as alternative, only one of the children features could
be included in every product that contains the parent;
• Or: if the relationship between a set of children nodes and their father is
deﬁned as or, one or more of them could be included in every product
that contains the parent.
Our approach for developing families of business information systems is
based on introducing some SPL techniques. For that purpose, the feature
model is used in our approach for describing the set of business informa-
tion systems that are members of the business family, and for representing the
variability of each business information system. In addition, the introduction
of SPL techniques implies a reduction of development times and costs and a
quality improvement of the ﬁnal products.
1.3.3 Process Family Engineering
The Process Family Engineering (PFE)  approach explores the idea of
applying SPL philosophy for managing the variability of business information
systems. In PFE, feature models are used for representing the set of processes
contained into a business. In addition, a business process diagram notation,
1.3. Research Context 15
Number of Seats <<VarPoint >> <<Null>>
<< Abstract >> > 100 Send Tickets Book Tickets
<<Implementation >> <<Implementation >>
Number of Seats > 50 <<Inheritance >>
<< VarPoint >> <<VarPoint >>
<< Default >> Inform by
Inform by Send Tickets
Intranet and Information
(A) Alternative Behavior (B) Parameterization (C) Inheritance (D) Extension Point
Figure 1.5: Variability aspects deﬁned by the PFE approach.
such as BPMN, is used for representing an speciﬁc process. However, the syn-
tax of this notation is redeﬁned for providing support for representing highly
variable business process models, namely variant-rich business process mod-
The PFE approach deﬁnes a variant-rich business process model as a pro-
cess model that represents how to deal with some identiﬁed variability as-
• Alternative behaviors: it deﬁnes when there exists several different
ways for performing an activity into a business process deﬁnition. Fig-
ure §1.5.a shows an example about a reﬁnement of the Inform business
process from the WSCI case study, represented using BPMN. When the
Airline Trafﬁc Control System submit some information to the Travel
Agencies it could be done by e-mail, publishing the information as a
new into the Intranet, etc. As shown, the PFE approach introduces some
stereotypes: (i) Abstract , for deﬁning the activity that has an al-
ternative behavior; (ii) VarPoint , for identifying the activities that
implements each possible behavior, this stereotype sometimes is repre-
sented as a puzzle piece into the activity; and (iii) Implementation ,
for describing a new kind of ﬂow not deﬁned in the standard BPMN
notation, that represents that an activity marked as VarPoint imple-
ments the behavior of other activity marked as Abstract . In addi-
tion, the default implementation can be provided introducing the stereo-
type Default .
• Parameterization: it deﬁnes that each BPMN attribute can be parameter-
ized to support a range of values. Figure §1.5.b shows how to represent
possible ranges of the value Number of Seats, into the subprocess Ver-
ify Seats Availability from the case study of this paper. This attribute is
16 Chapter 1. Introduction
marked using a grouping box and associated to other possible values by
means of a new association ﬂow deﬁned with a new stereotype named
• Inheritance: it deﬁnes a modiﬁcation of an existing subprocess by
adding or removing elements regarding to speciﬁc rules. This allows
for realizing alternative variation points. As shown in Figure §1.5.c, the
business process Send Tickets has been modiﬁed to Send Tickets and In-
formation about Trip since to the Travel Agency has a contract with some
tourism companies for providing information about them when it sends
tickets to the Traveler. This situation is marked with a new association
deﬁned using the stereotype Inheritance .
• Extension Points: it deﬁnes an optional behavior. Figure §1.5.d depicts
how an optional behavior from Book Tickets subprocess could be in-
cluded for quality assurance of this activity. This situation is marked
using the stereotype Extension .
The main difference between SPL and PFE is that the SPL ﬁeld provides a
set of different products that shares common features, and the PFE approach
provides only one product, which represents a business, that evolves at run-
time, and each possible conﬁguration of this business is managed as a product
that contains a subset of processes enabled at a certain moment of the execu-
tion. On the one hand, the SPL products are implemented by software arti-
facts. For each of them there exists a feature selection phase that generates
the ﬁnal products (a set of core and variable features). On the other hand, the
PFE products are implemented by processes. For each product, the system can
evolve to another product increasing or decreasing the variable set of features
thus, each product is a software system based on processes.
However, although the PFE approach proposes a methodology for design-
ing highly variable business processes, based on overcoming the complexity
derived from variability, by means of applying software product lines for man-
aging it; this approach presents some drawbacks. For example, the use of fea-
ture models and the derivation of business processes from it presents some
problems, such as ambiguity, that has been explored for us in . Another
consideration is the need of redeﬁning the BPMN syntax introducing some in-
formation about variability which is also present in the feature models, thus,
information is duplicated with the obvious problems for maintenance. In ad-
dition, there not exists support for this new syntax of BPMN, because it is not
an standard notation.
Our approach overcomes the variability of the business information sys-
tems using SPL techniques, taking into account the PFE approach ideas and
1.4. Hypothesis 17
without providing extra information to the standard notation used to repre-
sent the business process models. In addition, as stated previously, each PFE
product is considered as an evolving system. Our approach takes into account
this advantage for representing the evolution of the business information sys-
tems of the family.
In this section, we state the hypothesis and research questions that moti-
vate this research report and our future research in the context of the design
of business families. These are:
Hypothesis: Current process engineers redesign each Business Informa-
tion System using ad hoc techniques to maximize the level of reuse from one
product to another. Our hypothesis states that the reuse across businesses by
means of Software Product Line (SPL) techniques can be exploited. It means
that is feasible the deﬁnition of Business Families.
Increasing the business process deﬁnitions reusability is an active ﬁeld of
research in the Business Driven-Development (BDD) community [3, 14, 26, 32,
51, 52]. Our hypothesis raises the following research questions:
• Business Families. Does it makes sense?.
A discussion about the advantages and drawbacks of this idea should be
provided. This discussion should include a preliminary deﬁnition about
what is considered a business family and its main problems and beneﬁts.
• The Software Product Line (SPL) ﬁeld has a lot of beneﬁts and Business
Process Management too, How many beneﬁts have SPL and BPM to-
In order to explore the beneﬁts of our approach, a discussion about the
advantages and drawbacks of both ﬁelds and how many beneﬁts have
together should be provided.
• How many approaches explores the idea of introduce SPL techniques in
the Business-Driven Development (BDD) ﬁeld?
The related work of this topic should be revised, studying the advan-
tages and drawbacks of the current proposals and exploring how to in-
tegrate them into our approach.
18 Chapter 1. Introduction
Hypothesis: The design of highly variable business process models of a
Business Information System, member of a business family, could be partially
supported by means of an automated treatment.
Nowadays, variability is one of the most active topics in several academic
and industry communities [47, 55, 57]. Introducing variability support in the
BDD ﬁeld raises the following research questions:
• What kind of variability aspects can be performed on deﬁning business
A preliminary survey about the variability aspects identiﬁed on the de-
sign of a business process should be deﬁned. This survey should include
the methods and techniques used to deﬁne these variability aspects and
its advantages and drawbacks.
• How many approaches provides variability support on designing Busi-
ness Information Systems (BIS)?
The related work of this topic should be revised, studying the advan-
tages and drawbacks of the current proposals and exploring how to in-
tegrate them into our approach.
• How many kinds of variability are present in the deﬁnition of a BIS and
how are them represented?
A discussion about how many kinds of variability are present in the def-
inition of a BIS should be provided. A company evolves continuously,
thus not only static variability should be supported in our approach.
In addition, the representation techniques used to describe these kind
of variability should be revised. Another important issue is to study
the treatment of these variability deﬁnitions (manually or automated)
and its main beneﬁts and drawbacks including topics such as variability
analysis and visualization.
Hypothesis: Current proposals for modeling choreographies does not pro-
vide any support for introducing variability aspects into the design of busi-
ness families. Our hypothesis states that deﬁning a choreography model using
Agent-Oriented Software Engineering (AOSE) techniques makes feasible the
variability support and an automated treatment for obtaining collaboration
scenarios and behavior interfaces.
Modeling choreographies is one of the most active and recent topics in the
Business-Driven Development ﬁeld†3 [19, 20, 23, 64]. Our hypothesis raises
the following research questions:
1.5. Research Methodology 19
(ATL, Eclipse SOA Tool Platform, …)
( Business Driven Development, Software Product Lines,
Model Driven Development, Agent Oriented Software Engineering)
( BPMN, WSCI, BPEL)
( Automata Theory and Formal Languages,
Context-Free Grammars, Finite State Machines, …)
Figure 1.6: Proposed Holistic Framework.
• How many current proposals for modeling choreographies deals with
The related work of this topic should be revised, exploring the proposed
techniques for modeling choreographies and its variability support.
• How many current proposals for modeling choreographies provides an
automated treatment for obtaining collaboration scenarios and behavior
The related work of this topic should be revised, describing the beneﬁts
and drawbacks of current notations for designing choreographies and
its automated treatment.
1.5 Research Methodology
Our research methodology is based on providing an approach which sat-
isﬁes the following proposed holistic framework. This framework is divided
into four layers as shown in Figure §1.6. These layers are deﬁned as follows:
• Abstract Layer: this layer provides an abstract and formal deﬁnition of
the core elements of our approach. Concretely, our approach is focused
on the deﬁnition of several identiﬁed artifacts using several speciﬁca-
tions such as, context-free grammars, ﬁnite state machines, etc.
• Characteristic Layer: this layer provides several standard speciﬁcations
that must be supported by our approach. It means that all the elements
20 Chapter 1. Introduction
deﬁned in the abstract layer must have its equivalent representation by
means of at least one of these considered speciﬁcations.
• Operational Layer: this layer provides the set of development paradigms
that are exploited in our approach. The operational paradigm layer de-
pends on the standard speciﬁcation deﬁned in the previous characteristic
layer used to deﬁne some elements of our approach. Our approach must
satisfy the constraints of these paradigms without adapting or extending
its elements for our purpose.
• Implementation Layer: this layer provides a real implementation of the
operational paradigms used. In this layer a set of implementation tech-
niques and software tools are contained. As far as possible, the aim
should be to make use of generic techniques and tools that are not nec-
essary to adapt to our needs.
1.6 Goals and Structure of this research report
The goals of this research report are deﬁned as follows:
• Provide a review of the State of Art: Based on the hypothesis and re-
search questions presented in Section §1.4, we identify several topics
whose state of the art must be revised.
• Propose an approach for designing business families: Taking into ac-
count the main advantages and drawbacks of revised proposals, to pro-
vide an approach for making feasible the design of business families is
considered a goal of this report.
• Overview of our contributions: Although the results of our research are
still in a very preliminary stage we already have made some contribu-
tions. Giving a brief overview of them is also one of the goals of this
• Future work: Conclude this research report with the main conclusions
of this work by means of the answer to the research questions and a
dissertation about our future work, is a goal of this report.
This research report is structured in four parts: Preface, State of Art, Our
Approach, and Contributions. Figure §1.7 depicts the recommended reading
process of this report.
1.6. Goals and Structure of this research report 21
Part 1: Preface
Motivation Hypothesis Goals
Part 2: State of Art Part 3: Our Approach
SPL and BPM Family
Part 4: Contributions
Figure 1.7: Recommended reading process of this report.
The ﬁrst part is focused on providing a brief summary about the motiva-
tion of our research and the hypothesis and research questions that underlie
In the second part, we review the state of art of our research context. In
Chapter §2, we explore the current proposals based on the introduction of
SPL ideas into BPM in order to perform a systematic generation and reuse of
business processes across different companies. After that, a summary about
how many kinds of variability are present in the deﬁnition of a BIS is provided
in Chapter §3.
The third part is divided into the Chapters §4, §5, and §6. In this part,
we provide our approach for performing business families, named Business
22 Chapter 1. Introduction
Family Engineering (BFE). We focus our efforts on providing a BFE software
process deﬁnition for obtaining the core architecture of a business family, and
exploring how to deal with variability on choreography modeling of business
families using our approach.
Finally, in the last part, in Chapter §7, we provide a brief description of our
current contributions in this research context and, in addition, we summarize
our main conclusions and describe our future work.
Software Product Lines & Business
N owadays, one of the most active topics in the Business Process Man-
agement (BPM) research community is exploring how to increase the
reuse of business process deﬁnitions. For that purpose, several approaches has
been proposed. The main motivation of this chapter is to provide a revision of
these approaches, concretely exploring those which proposes the use of Soft-
ware Product Lines (SPL) techniques.
In Section §2.1, we present a summary of all the proposals that explore
the reuse of business processes. Then, the rest of the chapter focuses on the
Process Family Engineering (PFE) approach, which is the only one that pro-
pose the introduction of SPL techniques in the traditional design of Business
26 Chapter 2. Software Product Lines & Business Process Management
The SPL ﬁeld tries to overcome the growing complexity of current software
by maximising the level of reuse. Roughly speaking, the software process of
an SPL approach cover is performed in three parallel activities: (i) Domain
Engineering : in charge of deﬁning the SPL; (ii) Application Engineering : in
charge of deriving an speciﬁc product from the deﬁnition performed at do-
main engineering; and (iii) Product Line Management : devoted to the techni-
cal and organizational management of domain and application engineering.
See Chapter §1, Section §1.3.2 for a more detailed description about SPL.
In the Business Process Management (BPM) context, and concretely in the
Business-Driven Development (BDD) ﬁeld, increasing the level of reuse of the
business process deﬁnitions is considered a core need. Thus, since to SPL
deals with this issue, several approaches proposes the use of SPL techniques
in order to maximising the reusability of the process deﬁnitions.
According to , to perform a survey in the software engineering ﬁeld, we
have to deﬁne an analysis framework with the following components:
• Research questions: How many approaches explore the reuse of busi-
ness process models? and concretely, How many approaches explores
the idea of introduce SPL techniques in the Business-Driven Develop-
ment (BDD) ﬁeld? (This last research question has been introduced in
Chapter §1, Section §1.4)
• Search strategy to select sources:we have searched the bibliography ap-
pearing at DBLP, Google Scholar and ISI Web of Knowledge choosing
those papers with a higher number of cites; and ﬁnally a
• Catalogue: we classify the approaches in those focused on applying SPL
techniques, and those focused on other ﬁelds.
After searching the selected sources, we have found the following propos-
• Bayer et al.: proposes the Process Family Engineering (PFE) approach
for modeling variant-rich processes and reuse its deﬁnitions into a prod-
uct line architecture. This approach has been introduced in Section §1.3.3
previously. The PFE approach explores the idea of using feature models
(see Section §1.3.2 for a more detailed description about feature models)
for managing variability in a business information system context, but
2.2. Process Family Engineering (PFE) 27
the relationship between these feature models and its products, deﬁned
by means of business process models, is not clearly deﬁned . In ad-
dition, the PFE approach identiﬁes some variability aspects in business
process models, and proposes to introduce some stereotypes for rep-
resenting it. This redeﬁnition of the syntax implies some maintenance
drawbacks identiﬁed in Section §2.2.
• Van der Aalst et al.: proposes an extension of YAWL (Yet Another
Workﬂow Language ), named extended workﬂow-nets (EWF-nets), for
performing conﬁgurable and reusable workﬂow deﬁnitions of business
processes. YAWL is a workﬂow modelling language inspired by Petri
nets for deﬁning business process models. However, although this ap-
proach provides a formalization of EWF-nets for deﬁning possible vari-
ations into a workﬂow, it does not provide support for other notations,
such as BPMN. In addition, the application of SPL techniques is not ex-
• Ciuksys et al.: proposes an approach to reuse of business processes
knowledge at domain engineering. For that purpose, it provides a pro-
cess ontology for introducing semantic information into a business pro-
cess model. Thus, this approach propose to analyse this semantic in-
formation for obtaining a commonality summary, but without deﬁning
how to represent these reusable assets.
Thus, to the best of our knowledge, the PFE approach is the only one that
propose the introduction of SPL techniques in the traditional design of Busi-
ness Information Systems. Taking into account the result of our survey, we
are going to describe in the following section the ideas proposed by the PFE
2.2 Process Family Engineering (PFE)
2.2.1 Research Context: the PESOA project
The Process Family Engineering (PFE) approach was deﬁned in the context
of the PESOA project. PESOA is the acronym of Process Family Engineering
in Service-Oriented Applications, and it is a cooperative research project sup-
ported by the german federal ministry of education and research (BMBF).
The PESOA project aims at developing methodologies and techniques for
modeling variant-rich processes and in the design and prototypical implemen-
28 Chapter 2. Software Product Lines & Business Process Management
Analysis Design Implementation
Analysis Design Implementation
Figure 2.1: Process Family Engineering Overview.
tation of a Process Family Engineering platform. This project is focused in two
domains: E-Business and automotive †1 .
The Process Family Engineering (PFE) approach is deﬁned as a method-
ological foundation for dealing with highly variable business process deﬁni-
tions. This methodological foundation consists on: (i) a Conceptual Model
for variant-rich processes, which deﬁnes the conceptual requirements needed
for deﬁning variant-rich processes in the E-Business and automotive domains;
and (ii) a process engineering process called the PESOA Process, which pro-
vides an approach for developing, using and maintaining families of processes
deﬁned by means of their conceptual model.
Figure §2.1 depicts the overview of the PFE approach. It is composed by
two activities named Domain and Application Engineering, based on the ac-
tivities performed in the SPL ﬁeld (deﬁned previously in Section §2.1), and in
a Process Family Infrastructure, which performs the management of the prod-
2.2. Process Family Engineering (PFE) 29
Product Line Engineering (SPL) Process Family Engineering (PFE)
Product Line Infrastructure Process Family Infrastructure
Product Line Artifact Variant-Rich Processes
Artifact Element BIS Deﬁnition
Feature Models Variability Models
Table 2.1: Mapping between the SPL and PFE ﬁelds.
uct line deﬁned. As shown in Figure, both domain and application engineer-
ing activities are composed by three phases, which are deﬁned as follows: (i)
Analysis : focused on obtaining the requirements of the process family mem-
bers; (ii) Design : focused on the design of the process family members, de-
ﬁned as variant-rich processes by means of the conceptual model proposed;
and (iii) Implementation : focused on providing an executable deﬁnition of
the variant-rich business processes.
Table §2.1 deﬁnes the mapping between the concepts from the SPL ﬁeld
and the PFE approach. First, we explore the equivalence between the prod-
uct line and the process family infrastructure. Both elements are focused on
providing technical and organizational support of domain and application en-
gineering. The difference between them is focused on the products that both
manage. On the one hand, in the SPL ﬁeld, the product line artifacts are com-
monly software artifacts deﬁnitions composed on artifact elements (require-
ments, design, code, etc.) and represented by means of feature models. On
the other hand, in the PFE approach, the artifacts are variant-rich processes
which are part of a BIS deﬁned by means of variability models (commonly
feature models too). However, although some equivalence between both re-
search ﬁelds has been explored, there exists several diferences between them
which are deﬁned in the following section.
2.2.3 Main differences between the SPL and PFE ﬁelds
In the same way that the SPL approach provides all the techniques needed
for enabling the mass production of software in a certain application domain,
the PFE approach provides all the techniques needed for enabling the mass
production of processes in a certain business.
However, althougth both ﬁelds are similar, the SPL approach produces a
30 Chapter 2. Software Product Lines & Business Process Management
Software Process Family
Product Line Engineering
Implemented by Implemented by
Product Line Artifact 1 Variant Rich Process 1
Product Line Artifact 2 Variant Rich Process 2
Product Line Artifact 3 Variant Rich Process 3
Product Line Artifact n Variant Rich Process n
Select features Select features
BIS (state 1) BIS (state 2) BIS (state m)
Product 1 Product 2 Product m
Core Processes Core Processes Core Processes
Core Artifacts Core Artifacts Core Artifacts ...
... Variation Variation
m products; m > 0 1 product
Figure 2.2: SPL and PFE approaches.
set of software systems while the PFE approach produces only one Business
Information System (BIS), deﬁned by means of variant-rich business process
designs. These business processes deﬁnitions represent all possible states for
which the BIS can evolve during its activity. Roughly speaking, in PFE, each
product represents an evolution of the BIS (at runtime). In this context, the
term product is deﬁned as a set of features that are enabled/disabled at a
certain moment, and the term evolution is deﬁned as a transition from one
product to another. Although there exists several products, only one software
system is produced by means of the PFE approach: a BIS which evolves at
Figure §2.2 sketches how SPL and PFE products are generated. In SPL a
product is composed of a set of common features and a set of variable fea-
tures. Common features appears in all products and variable features appears
under demand of products’s consumers. Observing a certain product of a SPL,
although it is described as a set of ﬁxed features, some features can be in use
in a certain moment and some not. Thus, in SPL the evolution of the system at
runtime is not taken into account in the feature model. In PFE each feature is
a process and all of them appear into the product, but at runtime there exists
a set of products based on selection of features/processes.
As can be observed in Figure §2.2, where we depict how SPL and PFE prod-
ucts are generated, SPL products are implemented by software artifacts that
for each of them there exists a feature selection phase that generates the ﬁnal
2.2. Process Family Engineering (PFE) 31
products (a set of core and variable features). PFE products are implemented
by processes that for each of them there exists an evolution in execution time
incrementing or decrementing the variable set of features. Each product is a
software system based on processes. In addition, as stated previously, PFE
considers that sometimes a feature represents an activity, sometimes a busi-
ness process, but without providing an equivalence deﬁnition. Thus, we can
say that in PFE there not exist a mapping relationship between feature models
and business process models. This ambiguity implies some drawbacks iden-
tiﬁed in the design phase of PFE that we deﬁne in Section §2.2.6.
2.2.4 Conceptual Model
The conceptual model of the PFE approach is devoted to deal with vari-
ability in the representation of business processes in the E-Business and the
automotive domain. Roughly speaking, this model contains all the elements
that can vary in the deﬁnition of a BIS in the speciﬁed domains. Figure §2.3
presents the conceptual model as an UML static structure.
The elements of the conceptual model are deﬁned as follows:
• Process: It is the core element of the model. For each process deﬁnition
the partner who performs the process (attribute Role ) and the execution
state of the process (attribute Execution State ) must be provided . The
PFE approach states that processes can vary. Regarding our case study
(See Section §1.2): Reserve Tickets subprocess could provide support for
different mechanisms for paying a reserve. The process Reserve Tickets
contains a variation point that offers three choices to resolve the variabil-
ity. Such choices can be: Reserve Tickets with Credit Card, Reserve Tick-
ets with Bank Transfer and Reserve Tickets per Telephone. Depending
on the choice selected by the user the Reserve Tickets will be resolved.
Thus, it implies that at design time the process engineer should know all
the possible choices or variations of a process. As shown in Figure §2.3,
a process is considered as activities and a composition of them speciﬁed
such as a Sequence, Parallel, Choice or Iteration
• Input/Output: These elements specify data objects that are gener-
ated/consumed in a process. Regarding the example: assuming a client
has selected to Reserve Tickets with Bank Transfer, the input form might
vary depending on the country where the bank belongs to. For example,
American bank codes might differ from the European ones. In addi-
tion, the invoices to be generated might have different representations
depending on where the order is delivered.
32 Chapter 2. Software Product Lines & Business Process Management
Environment Non-Functional Properties
State RealTime Safety Security
* Control Flow
1 - acquires
1 CompositeActivity Sequence
* * + Role
+ Execution State Parallel
* 1 1
* Data Flow
* * Iteration
Input Output 1
- throws * DataSource DataSink
Figure 2.3: Conceptual Model of the PFE approach.
• Data Source/Data Sink: Data sources produce data used as input, as for
example the return of an invocation to a web service. Data Sink con-
sume data produced as outputs, as for example a database that stores
results. In our case study, assuming that the client who has selected to
Reserve Tickets with Bank Transfer, has an account in an American bank,
a data source produced could be the account code in American format
provided by a third-party web service from his bank. A data sink for our
example could be a Content-Management System such as Alfresc o†2 as
a repository where store the invoices.
• Quality of Service: It is focused on providing some non-functional prop-
erties in order to improve a concrete business process, as for example
providing a security layer on Reserve Tickets with Bank Transfer process
using an standard speciﬁcation such as WS-Security †3 . The proposed
conceptual model only takes into account Security, Safety and Real Time
as non-functional properties.
2.2. Process Family Engineering (PFE) 33
• Scope: It is focused on providing business environments. Roughly
speaking, it provides some functionalities into the business process de-
pending on its attribute Role, as for example a set of permissions de-
pending on an authenticated business partner, such as an administrator.
Regarding our example, only an authenticated Travel Agent can Verify
• Variable: A variable is associated to a scope and a set of variables deﬁnes
a state. Variables hold data of process attributes (inputs, outputs, data
sources, data sinks, roles, and nonfunctional properties). In our case
study, a variable could be a reserved ticket identiﬁcation number.
• State: A state is a situation during the execution of a process, which is
characterized by the current variable assignments of its contained pro-
cesses. In the conceptual model, this is reﬂected by the aggregation from
the state concept to the variable concept, and through the relationship
between the scope and the process concepts. For example, in our case
study the state of a reserving transaction at a given time could be de-
scribed by: the process Reserve Tickets, and the payment method Bank
• Event: An event can be thrown by a data source or a process. In the case
of a data source, an event is thrown, when a special value or threshold
deﬁned for the data source has been reached. Something similar can
be assumed for a process that reaches a certain state. For example, in
our case study, the Order Trip process is triggered when is received a
message from a Traveler who wants to travel to an speciﬁc destiny. One
special kind of event is the exception. An exception can be used to deﬁne
a possible error in the execution of a process.
Once the elements has been explored, the PFE approach states that the aim
of this conceptual model is to provide a metamodel for modeling business
processes. For that purpose, this approach explores the use of several model-
ing notations such as UML Activity Diagrams or Business Process Modeling
Notation (BPMN) extending it depending on their domain needs.
2.2.5 The PESOA Process
This section presents in more detail the PESOA process proposed by the
PFE approach. Figure §2.4 presents a product ﬂow view of the domain frag-
ment of the PESOA process, which is the focus of our research. (A more de-
34 Chapter 2. Software Product Lines & Business Process Management
Processes Variant Rich
Generator DS Generator
Implement DS DS
Figure 2.4: Domain Fragment of the PESOA Process.
tailed description of the overall PESOA process is provided in ). This frag-
ment is divided into the following phases:
• Scoping: The main purpose of this process is to provide a requirements
capture of the desired Business Information System. For that purpose,
2.2. Process Family Engineering (PFE) 35
the process engineer must review into the Process Family Infrastructure
availables reusable deﬁnitions, denoted as Product Set in Figure §2.4.
As result, process engineers obtain a Domain Scope Deﬁnition. The PFE
approach does not provide any element and constraints for documenting
• Domain Analysis: The main purpose of this process is to provide a rep-
resentation of the desired Business Information System by means of a
variability model, such as a feature model. The domain scope deﬁnition
is used as input for identifying consists-of relationships among features.
Once the feature model is deﬁned, the process engineer must identify the
processes from this representation in order to provide a business process
model deﬁnition. For that purpose, a process requirements summary
must be provided too.
• Domain Design: The main purpose of this process is to derive a busi-
ness process model deﬁnition that deals with the variability of the de-
sired Business Information System. Thus, process engineers must de-
rive this representation from the feature model and the process require-
ments obtained in the domain analysis phase. Once this representation
is obtained, the variants and variation points of the business processes
are identiﬁed. Roughly speaking, the process engineer identify the pro-
cesses and the choices to resolve its variability as stated in Section §2.2.4.
Finally, this set of variation points is used as input for obtaining a con-
ﬁguration model for each of the members of the family.
• Domain Implementation: The main purpose of this process is to de-
ploying the business process model speciﬁcations into a process engine
that executes it and produces the desired Business Information System.
For that purpose, the PFE approach proposes the use of domain-speciﬁc
generators and components.
Although PFE may be the solution to obtain Business Information Systems
(BIS) based on variant-rich business process deﬁnitions and to manage its evo-
lution, the Design step of this approach, concretely the use of feature models
and the derivation of business processes from it, presents three main draw-
backs, deﬁned as follows:
• Ambiguity: PFE uses feature models to show the variability derived
from enabling/disabling feature/process; however, given that feature
36 Chapter 2. Software Product Lines & Business Process Management
models are devoted to represent design-time variability and not runtime
variability [25, 38], the approach redeﬁne the semantics of feature mod-
els implicitly, but without providing a deﬁnition for it.
• Maintenance: PFE extends the notation of BPMN to add information
about variability which is also present in the feature models, thus, in-
formation is duplicated with the obvious problems for maintenance. In
Chapter §3, we explore this extension and the drawbacks that it implies.
• Manual derivation: the relationship between a feature model and its
corresponding business process is not rigorously deﬁned, and the devel-
opment of the business process is performed manually using as input
the feature model, what makes this activity error-prone and hinders the
maintainability of both kind of models.
In addition, as shown in Section §2.2.3, the PFE approach does not provide
a family of software systems, only one BIS (the ﬁnal product) which evolves
at runtime. This evolution is managed by means of SPL techniques but PFE
does not provide any representation for modeling it.
Variability in Business Information
I n common language use, the term variability refers to the ability or the
tendency to change . Thus, variability is one of the critical aspects of
a Software Product Line (SPL) infrastructure and it must be managed at all
the stages of development. Consequently, several approaches explores how to
integrate variability into the Business Process Management (BPM) domain in
order to provide ﬂexible Service-Oriented Architectured (SOA) systems.
The main purpose of this chapter is to provide an study about variability
into our research context. Thus, Section §3.1 explore what kind of variability
aspects can be performed on deﬁning business processes, and how many ap-
proaches provides variability support on designing Business Information Sys-
tems (BIS). Since to the PFE approach is the only one that covers our needs, we
explore these research questions (proposed in Chapter §1, Section §1.4) within
the context of that proposal in Sections §3.2 and §3.3. Finally, in Section §3.4,
we explore the binding time of identiﬁed variability aspects.
38 Chapter 3. Variability in Business Information System Design
Variability is one of the critical aspects of Software Product Lines (SPL). It
must be managed at all the stages of SPL development, and in every of them,
it appears in a polymorphic way which motivates the arising of different kinds
of variability. This double facet of variability and its importance in SPL, have
promoted an important amount of research approaches aimed to model and
Pohl et al. introduces in  all the questions that a well-formed docu-
mentation of variability must fulﬁl. An adequate documentation of variabil-
ity deﬁnition should at least include all the information needed to answer the
• What varies?: the variable properties of the different development arti-
facts have to be explicitly deﬁned and documented.
• Why does it vary?: all the causes of variability have to be captured and
explicitly deﬁned and documented.
• How does it vary?: documenting all the available choices and linking
them to domain model elements
• For whom is it deﬁned and documented? to deﬁne the audience of a
variation point (what varies) and/or its variants (available choices).
Derived from Software Product Lines appears an approach, into the
Business-Driven Development context, named Process Family Engineering
(PFE) . The PFE approach explores how to increase the reusability of the
process deﬁnitions and how to model highly variable business process. Con-
sequently, the enterprises beneﬁts would increase since to the reuse and self-
automatization in the process design phase will decrease the development
costs of Business Information Systems.
Therefore, we conduct an study of deﬁning Variability term, in the do-
main of the Process Family Engineering approach. The main purpose of this
chapter is to perform survey about the variability aspects identiﬁed in this ap-
proach. In addition, for each of them, we provide a deﬁnition based on Pohl