<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Experiencing Process Flexibility Patterns with Alaska Simulator</article-title>
      </title-group>
      <contrib-group>
        <aff id="aff0">
          <label>0</label>
          <institution>Barbara.Weber</institution>
          ,
          <addr-line>Jakob.Pinggera, Stefan.Zugal</addr-line>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Evolution Consulting</institution>
          ,
          <addr-line>Innsbruck</addr-line>
          ,
          <country country="AT">Austria</country>
        </aff>
        <aff id="aff2">
          <label>2</label>
          <institution>Quality Engineering Research Group, University of Innsbruck</institution>
          ,
          <country country="AT">Austria</country>
        </aff>
      </contrib-group>
      <abstract>
        <p>Alaska Simulator is an interactive software tool developed at the University of Innsbruck which allows people to explore di erent approaches to process exibility by using a familiar metaphor, i.e., travel planning and execution. In addition, Alaska Simulator is used for studying research questions in the context of business process management and other related elds. For this, Alaska Simulator provides integrated support of di erent approaches to process exibility in terms of decision deferral patterns, which all allow interleaving process modeling with execution and provide mechanisms for e ectively dealing with uncertainty. The biggest challenge for users of such exible systems is to nd the right balance between pre-planning activities and keeping options open. To address this challenge Alaska Simulator allows safe exploration and systematic investigation of how much pre-modeling is needed under different circumstances.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>
        1 Introduction
Alaska Simulator has been developed to support the teaching of di erent
approaches for process exibility and to investigate their strengths and weaknesses
through the execution of controlled experiments. Due to the many similarities
between modeling and executing business processes and journey planning Alaska
Simulator uses a journey as a metaphor 1. The used metaphor is not only helpful
to explain di erent exibility approaches to people without signi cant experience
in business process management, but is also an attractive context to be engaged
in, thus increasing the willingness of subjects to participate in experiments. In
the following, we describe the di erent approaches for process exibility
supported by Alaska Simulator (cf. Section 2), participating roles in the form of
personas [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ] and how they can work with and bene t from Alaska Simulator (cf.
Section 3).
1 For a detailed description of the journey metaphor visit the simulator's website:
http://www.alaskasimulator.org
2 Process Flexibility Support in Alaska Simulator
In today's dynamic business world the economic success of an enterprise
depends on its ability to react to changes in its environment in a quick and exible
way. To address this need several approaches for exible process support have
been proposed. All of these approaches address the problem of process change
either through structural modi cations of a prede ned work ow (e.g., adaptive
work ows [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ]) or the introduction of more exible execution models, which allow
users to defer decisions regarding the exact control- ow to run-time (e.g., Late
Binding, Late Modeling or Late Composition, for an overview see [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ]).
Common to all these approaches is the fact that they relax the strict separation of
build-time (i.e., planning) and run-time (i.e., execution), which has been typical
for plan-driven planning approaches as realized in traditional work ow
management systems (cf. Figure 1). They allow for a more agile approach by closely
interweaving process modeling and execution.
      </p>
      <p>No exibility for changing the process de nition during run-time is supported
by a traditional work ow system, i.e., the modeled process schema cannot be
altered at run-time. The Late Binding pattern provides exibility by allowing
for the introduction of a placeholder during modeling. At run-time the user
de nes the content of the placeholder by selecting the most appropriate process
fragment from a pre-de ned set. Late Modeling further extends the concept
of Late Binding by enabling the user to model the content of the placeholder
during run-time { the activities users can insert may be restricted when creating
the process Dmoifdfeelr.eLnatteFCleomxipboisliittiyonAopperrsoathcehheigshest degree of exibility58by
allowing the user to exibly compose the businesss process at run-time and to
freely switch between process modeling and execution.</p>
      <p>h
g
i
H
tr
o
p
p
u
S
r
e
s
U
fr
o
d
e
e
N
w
o
L
Low</p>
    </sec>
    <sec id="sec-2">
      <title>Late Composition</title>
    </sec>
    <sec id="sec-3">
      <title>Late Modeling</title>
    </sec>
    <sec id="sec-4">
      <title>Traditional</title>
    </sec>
    <sec id="sec-5">
      <title>Workflow</title>
    </sec>
    <sec id="sec-6">
      <title>Support</title>
    </sec>
    <sec id="sec-7">
      <title>Late Binding</title>
    </sec>
    <sec id="sec-8">
      <title>Degree of Flexibility</title>
    </sec>
    <sec id="sec-9">
      <title>High</title>
      <p>Alaska Simulator is the rst tool providing integrated support for all of these
decision deferral patterns fostering the systematic comparison of their strengths
and weaknesses in a training environment.</p>
      <p>
        Experiencing Process Flexibility Patterns with Alaska Simulator
3 Major Roles and Main Functionalities
AST consists of three major components: Alaska Simulator, Alaska Con gurator
and Alaska Analyzer. This section describes participating roles in the form of
personas [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ] and explains how they can interact with and bene t from the Alaska
Simulator Toolset (AST).
{ Steve Student: tests and analyzes his planning behavior with the simulator
and explores how much planning is just enough under di erent circumstances
{ Rose Researcher: investigates the strengths and weaknesses of di erent
approaches to process exibility using the simulator (for example see [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ] for the
results of a recently conducted experiment using Alaska Simulator)
{ Isabel Instructor: demonstrates the di erent exibility approaches using a
journey as a metaphor and explains the major di erences between these
techniques
The major features of AST are as follows:
{ Design journey scenarios: Alaska Con gurator allows researchers and
instructors to design their own journey scenarios including locations, actions,
events, constraints as well as the degree of uncertainty (cf. Fig. 3)
{ Plan and execute journeys : Alaska Simulator allows to plan and execute
journeys using di erent approaches to process exibility (cf. Fig. 2)
{ Log journeys: Each step that is performed while planning and executing
a journey is logged by Alaska Simulator for later investigation and detailed
analysis
{ Replay journeys: To enable interactive analysis of planning behavior,
journeys can be replayed step by step in Alaska Simulator
{ Analyze journeys: Instructors and researchers are supported in analyzing
the journeys after a planning session has been conducted with Alaska Analyzer
Alaska Simulator, including a test con guration, extensive documentation
and screencasts can be downloaded from http://www.alaskasimulator.org. Alaska
Con gurator and Alaska Analyzer are available to interested parties upon
request. For detailed information on the results of a controlled experiment which
was conducted using Alaska Simulator we refer to [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ].
      </p>
      <p>Incomplete information prior to execution is a characteristic of both journeys
and highly flexible business processes and is best handled by waiting until more
information is available (cf. Section 2.2). The outcome of a travel activity is
not predefined, as it can vary depending on the weather conditions during the
journey. When composing a concrete business case, different constraints like
selection constraints, ordering constraints or resource constraints have to be
considered (cf. Section 2.3), as similar constraints also exist when planning a
journey (e.g., mandatory activities, dependencies between activities, opening
times, budget)1.</p>
      <p>Barbara Weber , Stefan Zugal1, Jakob Pinggera1, and Werner Wild2
tool for planning and executing journeys (i.e., the business process); the Actions View
c  
(3) lists availabFlieg. a3cdteiopinctss. tThehgeraCphoicnasltursaeirnitnsterVfaiceewof (t2he) AolnasktahSeimruiglahtotr.tUosperscorner shows
constraints rceasntrciocmtpinosge tthheeir jinoduivrnideuya.l tTraovealpsslainstbythderagugsinegr aivnaildabelveealcotpioinnsgfroamctohnesistent plan,
the ProblemsaAvvaVaiililaaebbwllee a(At5c)atioppnaosrtinVictuieslwaro(ul3o)tcaoitnniotconotinnhsetihtsretaevmnealcppiel(as4n)a.(nE1)dx.isActicontngiosnctosrnaasrtiernatuinstvusaiolalyrleaotdniiolsy-ns. The Map
View (4) o eprlsayaend ionvtehrevCieownstorafinatllVlioewca(2t)ioannds haanvde tionbdeiccaontseisdetrhedewthreanvecolemrp'osscinugrarent location.
concrete journey. After each user action, the journey is validated and the user is
informed about any constraint violatio ns (5).
d  
e  
f  
Fig. 3. Alaska Con gurator allows users to compose journey con gurations including
actions (1), locations (2), constraints (3+4) and events to set up controlled experiments</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Cooper</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>The Inmates Are Running the Asylum</article-title>
          .
          <source>Sams</source>
          (
          <year>1999</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Reichert</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dadam</surname>
            ,
            <given-names>P.:</given-names>
          </string-name>
          <article-title>ADEPTflex { Supporting Dynamic Changes of Work ows Without Losing Control</article-title>
          .
          <source>JIIS 10</source>
          (
          <year>1998</year>
          )
          <volume>93</volume>
          {
          <fpage>129</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Weber</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Reichert</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rinderle</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>Change Patterns and Change Support Features - Enhancing Flexibility in Process-Aware Information Systems</article-title>
          .
          <source>Data Knowledge Engineering</source>
          <volume>66</volume>
          (
          <year>2008</year>
          )
          <volume>438</volume>
          {
          <fpage>466</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Weber</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Reijers</surname>
            ,
            <given-names>H.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Zugal</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wild</surname>
            ,
            <given-names>W.:</given-names>
          </string-name>
          <article-title>The declarative approach to business process execution: An empirical test</article-title>
          .
          <source>In: Proc. CAiSE'09</source>
          . (
          <year>2009</year>
          )
          <volume>470</volume>
          {
          <fpage>485</fpage>
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>