Abstract. This paper argues that an explicit account of rationale is essential for the effective management and evolution of semi-structured processes. Our approach is based on a view of semi-structured process models as unfinished products whose design is implicitly completed through their execution by process model users. The resulting refinements and modifications of the process models are instances of user-driven design innovation. Our framework shows how rationale can explain a user’s individual execution decisions, as a basis for process modelers to improve the original process specifications. We propose and illustrate a modeling approach using the FBS ontology

Liming Zhu

Udo Kannengiesser

CiteSeerX

Rationale in Semi-Structured Processes 
Udo Kannengiesser1 and Liming Zhu1 
 
1 NICTA, Australia, and 
School of Computer Science and Engineering, University of New South Wales, Sydney, 
Australia 
{udo.kannengiesser, liming.zhu}@nicta.com.au 
Abstract. This paper argues that an explicit account of rationale is essential for 
the e f f e c t i v e  m a n a g e m e n t  a n d  e v o l u t i o n  o f  s e m i -structured  processes.  Our 
approach is based on a view of semi-structured process models as unfinished 
products  whose  design  is  implicitly  completed  through t h e i r  e x e c u t i o n  b y  
process model users. The resulting refinements and modifications of the process 
models are instances of user-driven design innovation. Our framework shows 
how rationale can explain a user’s individual execution decisions, as a basis for 
process modelers to improve the original process specifications. We propose 
and illustrate a modeling approach using the FBS ontology. 
Keywords: Semi-structured processes; rationale; function-behavior-structure 
1   Introduction 
In semi-structured processes, not all process information is fixed or known at design 
time [1]. Traditional approaches to business process management (BPM) are poorly 
suited for this class of processes, because of their underlying assumption that all tasks, 
roles and artifacts in a process are fixed and well defined prior to execution. Their 
applicability is often restricted to specifying high-level process models, and supplying 
organizational and IT infrastructures that allow for fast response to changing process 
environments.  The  expertise  required  for  “filling  in  the  blanks”  and  adapting  the 
process to the situation at hand resides in the human users of the process models. 
Explicitly capturing the assumptions that underpin the users’ execution choices may 
be a basis for a more effective management of these processes. 
This  paper  explores  this  issue  by  adopting  a  design  stance.  An  inherent 
characteristic  of  designing  is  that  it  generates  the  structure  of  “things”  based  on 
knowledge  about  their  usefulness  and  applicability  in s p e c i f i c  e n v i r o n m e n t s .  
Representations of this knowledge as goals and assumptions that explain individual 
design decisions are referred to as design rationale [2]. Rationale may relate to any 
kind of design, including the design of process models and process executions. For 
example,  the  rationale  associated  with  the  decision  to  use a  s t a n d a r d  s p r e a d s h e e t  
application for data analysis may include the goals of transparency and reproducibility 
(because, unlike traditional, non-programmable calculators, spreadsheets enforce the 
capture  of  all  mathematical  operations)  and  cost  considerations  (as  standard applications are usually cheaper to acquire than most specialized applications). This 
paper  presents  the  role  of  rationale  in  managing  semi-structured  processes a n d  
proposes a modeling approach. 
2   Process Model Use as Process Design 
Semi-structured  processes  can  be  viewed  as  unfinished  products,  whose  design  is 
implicitly  completed  by  their  users  as  they  execute  them.  There  are  a  number  of 
examples  in  other  domains  where  the  use  of  designed  objects  includes  design 
activities. For example, mass-customized products defer some design or configuration 
decisions to their users [3]. Most physical materials are designed for being used in the 
design of other objects. For example, certain fibers may be used in the design of 
certain textiles, which in turn may be used in the design of certain pieces of clothing, 
and so on [4]. The same applies to virtual materials such as software libraries, which 
are designed so that programmers can use them for their own software designs. In 
case of open-source software, the intended use includes activities of re-designing the 
software itself. Software is particularly well suited for being used for re-designing, as 
modifications are generally less costly than for physical objects [5]. 
Many processes in the domains of business and science can be seen as virtual 
objects, similar to software. Models of these processes are used for designing actions 
resulting in a “real” (or executed) process. This idea follows Simon’s [6] broad claim 
that “everyone designs who devises a course of action aimed at changing existing 
situations into preferred ones”. When the course of actions (i.e., the executed process) 
is represented through a process model (e.g., using process mining), that model may 
or may not be consistent with the original process model. In case of the latter, one 
may interpret the model of the executed process as a re-designed process. 
The extent to which a process model constrains the (design) actions of its users 
varies  with  the  level  of  detail  provided  by  the  process  model  and  with  the 
enforcement mechanisms prevailing in the social or organizational context. Models of 
semi-structured processes are intended to allow a certain amount of “design freedom” 
[7] through their coarse-grained description of process elements and the expectation 
that  some  ad-hoc r e f i n e m e n t s  a n d  c h a n g e s  w i l l  b e  t o l e r a t e d .  R e c e n t  w o r k  o n  
modeling goals and context of processes and process fragments [8, 9, 10] can be used 
to enhance user guidance and compliance by constraining possible design actions. 
Providing process model users with constraints and then monitoring the resulting 
process execution can be used for achieving sufficiently controlled process flexibility. 
On the other hand, this approach cannot support reasoning about the relative benefits 
and drawbacks of alternative process structures beyond the pre-specified goals and 
constraints. This is because the user is viewed as a “black box”, and the rationale for 
the user’s decisions must be inferred from the executed process due to the lack of 
explicit representation of that rationale. As a result, this approach may be suitable for 
controlling compliance but is not appropriate for swiftly improving process structures 
in  response  to  problems,  opportunities,  or  new  knowledge  gained  from  previous 
process executions. There is a need for continuous interaction between designers and 
users of semi-structured process models that includes their rationale. 3   Rationale of User-Driven Process Innovation 
Using semi-structured process models can be viewed as an instance of user-driven 
innovation. An existing framework of design innovation [11] includes this notion by 
explicitly representing bi-directional interactions between producers (i.e., designers) 
and adopters (i.e., users) of designed objects. Figure 1 shows a specialization of this 
framework  for s e m i -structured  processes  as  the  objects  of  design  innovation. 
Producers and adopters can interact directly, and indirectly via a use environment that 
includes modeled and executed processes. Processes are assumed to comprise any 
combination of control-flow, data-flow and organizational aspects [12, 1]. 
 
 
Fig. 1. Producers and adopters of process models, and their interactions 
Producers specify process models, provide process constraints, and monitor the 
execution of the resulting processes. Adopters interpret the specified process models, 
realize  (i.e.,  execute)  them,  and  provide  process  rationale  to  producers.  Both 
producers and adopters interact based on their individual expertise and strategies that 
change over time as they learn from their interactions. This, in turn, affects the kinds 
of information represented in the process models, the constraints and the rationale. 
Rationale provides a basis for analyzing an adopter’s assumptions and reasoning 
that  can  explain  any  refinements  or  changes  of  the  original  process  model.  It 
addresses an important aspect of provenance that is often neglected in the process 
domain, viz. the “why” of particular execution choices [13]. The insights gained from 
rationale can be used in two ways. First, producers can identify misinterpretations and 
eliminate them through clarified or more complete models of the process structure 
and constraints. Second, producers can recognize potential process improvements or 
pitfalls, and respond to them by changing the original process models and constraints. 
If BPM tools are to be made more effective for semi-structured processes, they 
should support the capture and exchange of rationale between adopters and producers. 
4   Modeling Rationale 
The function-behavior-structure  (FBS)  ontology  [14,  15]  represents  design  objects 
irrespectively of the particular domain of designing. Function (F) is defined as an object’s teleology (“what the object is for”). It is the 
usefulness ascribed to the object. Typical functions of processes include process goals 
(e.g., “to generate purchase orders”) and quality goals (e.g., “efficiency”). 
Behavior ( B)  i s  de f i ne d a s  t he  a t t r i but e s  t ha t  c a n be  de r i ve d f r om t he  obj e c t ’ s  
structure  and  its  interactions  with  the  environment.  Behavior  provides  measurable 
criteria for evaluating and selecting different structures based on their applicability in 
different contexts. Process behaviors often relate to accuracy, speed and cost. 
Structure (S) is defined as an object’s components and their relationships. The 
structure  of  processes  comprises  their  interconnected  inputs,  transformations 
(including resources and sub-processes) and outputs. 
The FBS ontology supports all the interactions shown in Figure 1. The notion of 
structure  captures  the  various  elements  of  modeled  and  executed  processes  (e.g., 
tasks,  resources  and  data),  and  the  notions  of  function  and  behavior  capture  the 
producer’s constraints as well as the adopter’s rationale for decisions on structure [2, 
16].  This  uniform  representation  of  all  interactions  allows  for  direct  comparisons 
between the modeled and the executed process structure, and between the producer’s 
constraints and the adopter’s rationale. Adopters can use these comparisons to choose 
those parts of their rationale that are of most interest to a producer. With respect to a 
given set of constraints, rationale can represent (1) subsumptions (i.e., same or similar 
behavior values), (2) improvements (i.e., significantly “better” behavior values), or (3) 
expansions (i.e., additional classes of behavior or function). Those parts of a rationale 
that are subsumptions of (i.e., that are subsumed by) constraints are usually of little 
value, unless suspected misinterpretations need to be addressed. Improvements and 
expansions, however, are most relevant and should be made available to producers so 
that  they  can  adapt  their  specifications  for  more  effective  or  efficient  process 
executions in the future. 
Typical examples of semi-structured processes are software development models, 
as they can be pre-defined only on a high level. Figure 2 shows the structure of such a 
process, specified by a producer in BPMN. Constraints are included via an annotation 
that specifies overall functions and behaviors required of the process. 
 
 
Fig. 2. A process model with annotated constraints, specified by a producer 
Figure  3  shows  a  model  of  an  executed  process  structure  and  the  rationale 
associated (via annotations) with those process parts that the adopter has modified. The rationale includes a significant behavior improvement (“total time” from 10 days 
to 7 days), achieved by tightly coupling the generate-and-test activities rather than 
executing them in sequence. The executed process also introduces a “firefighting” 
activity (“Deploy Additional Developers”) that aims to prevent development delays, 
which  also  expands  the  original  constraints  by  introducing a  n e w  b e h a v i o r  ( “ o n -
schedule rate”) and a new function (“reliability”). 
 
 
Fig. 3. A model of an executed process with annotated rationale, described by an adopter 
The producer is now in a position to analyze the reasoning that led to the adopter’s 
process changes, and to consider whether to modify the original process specifications 
either to formally integrate these changes, or to prevent them from being introduced 
by future process executions. In both cases, the producer’s decision can take account 
of assumptions of usefulness and applicability, both of which are included in the 
adopter’s rationale. 
5   Conclusion 
Semi-structured processes differ from fully-structured ones in that they tolerate and 
encourage flexible execution decisions that may refine or deviate from the specified 
process model. This relaxes the burden of having to specify a detailed and complete 
process structure. However, it also creates a stronger need for explicitly representing 
process function and behavior to more effectively manage process execution. These 
notions capture the usefulness and applicability of different process structures. They 
can  be  used  for  specifying  constraints  with  which  the  executed  process  needs  to 
comply.  Their  use  as  rationale,  as  proposed  in  this  paper,  allows  associating 
individual  execution  decisions  with  underlying  assumptions.  The  uniform 
representation of both constraints and rationale allows the producers and adopters of 
process models to directly compare each other’s assumptions about the process. This 
is  essential  for  adapting  their  interactions  and  thus  evolving  the  process  structure 
according to changes in the environment. The nature of our approach is conceptual. While we have illustrated it using BPMN 
models with annotations that are structured according to the FBS ontology, we do not 
intend to limit its use to any specific notation. And its “adoption” in practice will 
certainly  require  more  elaboration,  using  clearly  defined  annotation  schemas  and 
domain  vocabulary  to  unambiguously  represent,  capture  and  exchange  rationale 
between process stakeholders. 
 
Acknowledgments. NICTA is funded by the Australian Government as represented 
by the Department of Broadband, Communications and the Digital Economy and the 
Australian Research Council through the ICT Centre of Excellence program. 
References 
1.  Loeffeler, T., Striemer, R., Deiters, W.: A Framework for Identification, Classification and 
IT Support of Semi-Structured Business Processes. Knowledge and Process Management 5, 
51--57 (1998) 
2.  Lee, J.: Design Rationale Systems: Understanding the Issues. IEEE Expert 12, 78--85 (1997) 
3.  von Hippel, E., Katz, R.: Shifting Innovation to Users via Toolkits. Management Science 48, 
821--833 (2002) 
4.  Redström, J.: RE: Definitions of Use. Design Studies 29, 410--423 (2008) 
5.  Kruchten,  P.:  Casting  Software  Design  in  the  Function-Behavior-Structure  Framework. 
IEEE Software 22, 52--58 (2005) 
6.  Simon, H.A.: The Sciences of the Artificial. MIT Press, Cambridge (1996) 
7.  van  Aken,  J.E.:  Design  Science  and  Organization  Development  Interventions:  Aligning 
Business and Humanistic Values. Journal of Applied Behavioral Science 43, 67--88 (2007) 
8.  Soffer, P., Regev, G.: On the Notion of Soft-Goals in Business Process Modeling. Business 
Process Management Journal 11, 663--679 (2005) 
9.  Rosemann,  M.,  Recker,  J.,  Flender,  C.:  Contextualisation  of  Business  Processes. 
International Journal of Business Process Integration and Management 3, 47--60 (2008) 
10.  Kannengiesser,  U.:  Process  Flexibility:  A  Design  View  and  Specification  Schema.  In: 
Mendling, J., Rinderle-Ma, S., Esswein, W. (eds.) Enterprise Modelling and Information 
Systems Architectures 2009, pp. 111--124. University of Ulm, Germany (2009) 
11.  Gero, J.S., Kannengiesser, U.: Understanding Innovation as Change of Value Systems. In: 
Tan, R., Cao, G., León, N. (eds.) Growth and Development of Computer-Aided Innovation, 
pp. 249--257. Springer, Boston (2009) 
12.  Curtis, B., Kellner, M.I., Over, J.: Process Modeling. Communications of the ACM 35, 75--
90 (1992) 
13.  Ram,  S.,  Liu,  J.:  Understanding  the  Semantics  of  Data  Provenance  to  Support  Active 
Conceptual Modeling. In: Chen, P.P., Wong, L.Y. (eds.) Active Conceptual Modeling of 
Learning. LNCS, vol. 4512, pp. 17--29. Springer, Berlin (2007) 
14.  Gero,  J.S.:  Design  Prototypes:  A  Knowledge  Representation  Schema  for  Design.  AI 
Magazine 11, 26--36 (1990) 
15.  Gero,  J.S.,  Kannengiesser,  U.:  The  Situated  Function-Behaviour-Structure  Framework. 
Design Studies 25, 373--391 (2004) 
16.  Chandrasekaran,  B.,  Goel,  A.K.,  Iwasaki,  Y.:  Functional  Representation  as  Design 
Rationale. Computer 26, 48--56 (1993) 

Rationale in Semi-Structured Processes

http://www.nxp.com/documents/data_sheet/BYV34-600.pdf

Rationale in Semi-Structured Processes

Abstract

Similar works

Full text

Available Versions

CiteSeerX