A Data-Centric Design Methodology for Business Processes

Transcription

1 A Data-Cetric Desig Methodology for Busiess Processes Kamal Bhattacharya Richard Hull Jiawe Su IBM T.J. Watso IBM T.J. Watso UC Sata Barbara Abstract This chapter describes a desig methodology for busiess processes ad workflows that focuses first o busiess artifacts, which represet key (real or coceptual) busiess etities, icludig both the busiess-relevat data about them ad their macro-level lifecycles. Idividual workflow services (a.k.a. tasks) are the icorporated, by specifyig how they operate o the artifacts ad fit ito their lifecycles. The resultig workflow is specified i a particular artifact-cetric workflow model, which is itroduced usig a exteded example. At the logical level this workflow model is largely declarative, i cotrast with most traditioal workflow models which are procedural ad/or graph-based. The chapter icludes a discussio of how the declarative, artifact-cetric workflow specificatio ca be mapped ito a optimized physical realizatio. 1. INTRODUCTION Most traditioal workflow models are based o a procedural ad/or graph-based paradigm for specifyig how a busiess process or workflow is supposed to operate, ad methodologies to desig workflows i those models are typically fouded o a process-cetric perspective. This chapter describes a fudametally differet approach to workflow desig, which is fouded o a data-cetric perspective, ad which is especially useful for desigig the detailed operatio of busiess processes for eterprises i the moder era. The first major step i this data-cetric approach is to idetify the busiess artifacts, which correspod to key (real or coceptual) busiess etities that are to be maaged by the workflow. Examples iclude sales ivoices, isurace claims, shipmets, fiacig deals, ad customers. A busiess artifact icludes both busiess-relevat data about the busiess etity, alog with iformatio about the macro-level lifecycle that the etity moves through, icludig the key stages of the processig of the etity ad how they are or might be sequeced. The secod major step is to develop a detailed logical specificatio of the data eeded about each class of artifacts, the services (a.k.a. tasks) that will operate o the artifacts, ad the associatios betwee the services ad the artifacts. I cotrast with most workflow models used i idustry today, the services ad associatios are described i a declarative maer, usig pre-coditios ad coditioal effects for the services ad Evet- Coditio-Actio (ECA) rules for the associatios. The third ad fial major step is to map the declarative workflow specificatio ito a more procedural specificatio, which ca be optimized ad the mapped ito a physical implemetatio. I additio to describig the data-cetric desig methodology, this chapter describes a artifact-cetric workflow model which ca be used as the target for data-cetric workflow desig activities. A busiess process is a set of (typically liked) activities executed by various stakeholders to provide value to a customer without exposig the customer to the costs ad risks ivolved i deliverig value. With eterprises of today shiftig their busiess strategies from the more traditioal product focus to a customer focus, it is importat to be specific about how to orgaize busiess operatios to deliver busiess value ad eable growth. Busiess processes are a meas - 1 -

2 to operatioalize a busiess strategy ad have become a importat aspect of gaiig the leadig edge i the market place over competitors. Busiess processes are thereby a key elemet of a eterprise s survival kit ad a lever to esure growth ad most importatly, outperform competitors. Busiess process modelig is the act of represetig a busiess process i a format (ofte a graphical represetatio) that ca be used to commuicate the itet of a process to differet busiess stakeholders. The level of detail icluded i a busiess process model is determied by how the model is beig used. For example, providig guidace about process executio may oly require a step-by-step descriptio whereas usig a busiess process model as a driver for implemetig a complete workflow may require a much greater level of detail. Usig process models as a driver for implemetig workflow systems that will support busiess process executio poses sigificat desig challeges. I most curret approaches, activity-flows are desiged to specify the how processig is orgaized. Data is icorporated, but usually at a limited level that focuses o the iputs ad outputs of idividual services. As a result, it is hard to obtai a uderstadig of the overall possible effects of the overall sequece of processig steps o key busiess etities. I cotrast, data modelig is a crucial aspect of virtually all software desig approaches. The emergig busiess artifact paradigm described i this chapter gives data a foudatioal role i the cotext of busiess process desig. I particular, the otio of busiess artifact itroduces data as a first-class modelig primitive that will drive the process modelig. A busiess artifact holds all of the busiess-relevat data ad lifecycle iformatio of cocerig a key busiess etity. A busiess artifact-cetered modelig approach first idetifies these artifacts ad specifies their iformatio models (i.e., database schemas) ad their macro-level lifecycles. For example, a withdrawal request i a bak ca serve as the basis for a artifact, which specifies all the iformatio required for a certai bak trasactio. The lifecycle describes the various steps for how a withdrawal request artifact might be processed (from iitially fillig out the form to make the request to close of trasactio). The data i the withdrawal request artifact should be ecessary ad sufficiet to execute all the processig steps without ay ambiguity. The completio of each service (task) that works o the withdrawal request ca be viewed as a milestoe of the overall ed-to-ed trasactio. This chapter is focused primarily o busiess artifacts ad how these ca be used to provide core elemets of a overall desig methodology for busiess operatios. As such, may importat aspects of busiess process maagemet are ot discussed here. For example, while the otio of busiess artifact is a extremely useful coceptualizatio for busiess process desigers, the chapter does ot discuss user iterfaces or tools to help the desigers with documetig or viewig a desig. Similarly, user iterfaces ad their automatic geeratio for performig idividual services (tasks) maaged by the workflow are ot cosidered. The importat area of exceptios is ot discussed. Support for moitorig busiess processes, icludig the trackig of key performace idicators (KPIs) ad creatig dashboards for highlevel maagers, is ot covered. Maagemet of the overall lifecycle of busiess processes, icludig the evolutio of the busiess process desigs is ot addressed. Ad the use of busiess rules, which might express high-level goals ad costraits o the busiess operatios, ad might be specified usig the SBVR stadard, are ot discussed. I all of these cases, ad for may other aspects of busiess process, we believe that the desig methodology ad costructs described here provide a atural ad robust foudatio for their icorporatio. I this chapter, we preset a data-cetric methodology for busiess process desig. I Sectio - 2 -

3 2, the methodology is outlied i brief. Sectio 3 demostrates the key desig steps ad techiques of this methodology usig a example applicatio. Sectio 4 briefly discusses the beefits of usig a data-cetric methodology ad workflow model. Sectio 5 offers a summary ad coclusios. 2. THE DATA-CENTRIC DESIGN METHODOLOGY This sectio provides a overview of the data-cetric desig methodology. This methodology is based o a three-level framework, which is provides the structure for how high-level declarative busiess process models ca be mapped faithfully ito implemeted, procedural workflows. I Sectio 2.1, a rich family of possible artifact-cetric workflow models is described. I Sectio 2.2, the desig methodology itself is outlied. At the core of the data-cetric desig methodology is a three-level framework for busiess processes (Figure 1). At the top level, a Busiess Operatios Model (BOM) provides a detailed logical specificatio of busiess process executio. I the ruig example used i this chapter, i additio to busiess artifacts, the BOM icludes services specified i terms of their sematics (icludig pre-coditios ad coditioal effects), ad ECA rules. At the bottom level is the operatioal workflow system i which executable services commuicate with each Specificatio Optimizatio Executio BOM (artifacts, sematic services, ECA rules) Coceptual Flow (artifacts, service behaviors, choreography) Workflow (artifacts, executable services, messagig) Figure 1: Three Logical Levels of BPM other through messages ad maipulate artifacts. At the middle is the coceptual workflow that captures essetially the BOM i a procedural maer, while hidig implemetatio details. This level is suitable for optimizatio sice it allows for efficiet reasoig i the cotext of the physical requiremets for implemetatio, icludig possibly legacy systems ad distributio of the workflow across orgaizatios A family of possible artifact-cetric busiess process models There are may ways that the cetral otio of busiess artifact ca be used as the basis for a workflow model. Although the chapter is focused o a specific artifact-cetric workflow model, this sectio provides a more geeral overview of possible artifact-cetric workflow models. There are four key elemets i a artifact-cetric workflow model: busiess artifact iformatio model, busiess artifact macro-level lifecycle, services (tasks), ad the associatio of services to busiess artifacts. We use the term associatio here to idicate that the associatio might be specified i a largely declarative way usig rules or a much more procedural maer usig a flowchart or covetioal workflow model. Whe it is clear from the cotext, we sometimes use the term artifact to mea busiess artifact. I the followig, we give a brief explaatio of these four cocepts, while otig that the cocepts may take differet (sytactic ad sematic) forms i differet steps of desig. BUSINESS ARTIFACT INORMATION MODEL. The iformatio model (or database schema) of a - 3 -

4 busiess artifact is iteded to hold all of the iformatio eeded i completig busiess process executio i coectio with a give busiess etity. The artifact data should icorporate the iformatio eeded to (i) capture busiess process goals, ad (ii) allow for evaluatig how thoroughly these goals are achieved. Example data foud i artifacts iclude data that are received durig the busiess process executio from the exteral world, data that are produced by the executio, ad data that record the decisios take i the executio. A busiess artifact has a idetity ad ca be tracked as it progresses through the workflow. It ca have a set of attributes to store the data eeded for the workflow executio; i the geeral settig, both attributes ad their values ca be created, updated, or deleted by the services i the workflow. The attributes may be simple scalars or richly ested data structures. A good approach to modelig artifacts is to make them self-cotaied, i that all data eeded by the artifact is preset i the artifact. A subtlety arises whe oe artifact eeds to refer to aother oe. For example, a order artifact typically refers to a customer, which may also be represeted by a artifact. While it is appropriate to use the customer ID as a way to refer to a give customer, specific order-relevat data such as the shippig address of the customer, at the time the order was made, should be stored (either physically or virtually) as a part of the order. I busiess terms, a artifact represets the explicit kowledge cocerig progress toward a busiess operatioal goal at ay istat. Operatioal goals, such as processig a customer order, are measurable results that idividually ad i the aggregate satisfy the purpose of the busiess. The iformatio cotaied i the set of artifacts records all the iformatio about the busiess operatio. Hece, at ay time of executio, the rutime state of a busiess process is determied by the sapshot of all artifacts. BUSINESS ARTIFACT (MACRO-LEVEL) LIFECYCLE. I the data-cetric methodology, busiess artifacts combie, at a fudametal level, the iformatio model for key busiess etities alog with their macro-level lifecycle. I most cases the busiess stakeholders ca describe this macrolevel lifecycle i terms of stages i the possible evolutio of the artifact, from iceptio to fial dispositio ad archivig. I the artifact-cetric workflow model preseted i Sectio 3, the macro-level lifecycle of a give class of artifacts is represeted usig a variat of fiite state machies, where each state of the machie correspods to a possible stage i the life-cycle of a artifact from this class. I this variat of state machies, little or othig is idicated about why or how a artifact might move from oe stage to aother, although coditios may be attached to trasitios i the machie. Artifacts may have differig life expectacies. I some cases the artifact is relatively short-lived (e.g., a customer order), i other cases relatively log-lived (e.g., a customer, icludig a ogoig log of services to a customer, their preferece level for the eterprise, their perceived level of satisfactio), ad i yet other cases the artifact is essetially permaet (e.g., a artifact which holds the iformatio about a product type, icludig product descriptio, availability, ad purchasig treds). SERVICES. A service i a artifact-cetric busiess process ecapsulates a uit of work meaigful to the whole busiess process i at least two aspects. First, the potetial chages made by the service should reflect a measurable step (or steps) of progress towards the busiess goal. Secod, the divisio of the busiess process ito some collectio of services should be able to accommodate (expected) admiistrative orgaizatio structures, IT ifrastructures, customer

5 visible status, etc. Techically, a service makes chages to oe or more busiess artifacts, ad the chages should be trasactioal, i.e., a service should have (the effect of havig) exclusive cotrol over the ivolved artifacts whe makig these chages. The term service rather tha task is used here, to emphasize the close correspodece betwee the kid of services used here ad the kids of services foud i the Services Orieted Architecture (SOA) ad i web services i geeral. This is especially relevat as workflows will become icreasigly distributed i the future, both across sub-orgaizatios of a sigle orgaizatio, ad via the web across multiple idepedet orgaizatios. I the desig methodology, services are itroduced i Step 2 as sematic services (i the spirit of OWL-S). I Step 3, the service specificatios are exteded to iclude a specific implemetatio (typically expressed as a algorithm or i a programmig laguage). The executable services are the developed i Step 4. ASSOCIATIONS. I a busiess process services make chages to artifacts i a maer that is restricted by a family of costraits. These costraits might stem from a procedural specificatio (e.g., a flowchart) or from a declarative specificatio (e.g., a set of rules ad logical properties that must be satisfied). Some commo types of costraits iclude precedece relatioships amog the services, betwee services ad exteral evets (e.g., receivig a request), ad betwee services ad iteral evets (e.g., timeout). I may cases the costraits ivolve relative or absolute times, ad are thus temporal costraits. Associatio takes differet forms i the three logical levels of BPM. I Sectio 3, at the BOM level, the associatio is expressed i a largely declarative fashio, usig Evet-Coditio- Actio (ECA) rules (e.g., whe ivetory falls below 10%, if there are orders from good customers i the queue, the repleish ivetory quickly). At the Coceptual Flow level, the associatio is refied ito a global choreography, which provides at a logical level a more procedural specificatio of how data is distributed across cotaiers ad how service executio will occur (whe ad what actios to be take o artifacts residet i which cotaiers, based o what iteral or exteral evets ad/or other cosideratios). At the Workflow level, the associatio is expressed as a procedural workflow that is implemeted as executable services that commuicatig amog each other ad exterally. We use the acroym BALSA (for Busiess Artifacts with Lifecycle, Services, ad Associatios ) to refer to data-cetric workflow models that combie these basic buildig blocks. The BOM for the ruig example preseted i Sectio 3 shall use a particular variat of such models, called here BALSA basic. As will be see, the BALSA basic model uses the Etity- Relatioship data model to specify the format of artifacts, a framework for specifyig services stemmig from the Sematic Web Services literature, ad (logical-level) Evet-Coditio- Actio (ECA) rules for specifyig the associatios betwee services ad artifacts. A variety of other BALSA models ca be obtaied by varyig the paradigm used i specifyig the iformatio model, lifecycle, services, ad associatios are specified. The artifact iformatio model might be specified as attributes with scalar values, attributes with scalar or ested relatio values, attributes stemmig from ER schemas as i BALSA basic, or XML, to ame a few. The lifecycle might be specified usig flowcharts (with or without parallelism), fiite state machies as i BALSA basic, state charts, or declarative mechaisms based o ECA or CA, amog other choices. The services might be specified by givig details about their iteral fuctioig - 5 -

6 (e.g., usig flowcharts, state machies, BPEL), or i a more black-box maer by specifyig oly their I/O properties, or i a gray-box maer as i BALSA basic usig I/O ad also pread post-coditios, amog other possibilities. There is a fuzzy boudary betwee the paradigm used for specifyig lifecycles ad the paradigm used for specifyig associatios. For example, geeralizatio of BALSA basic could be obtaied by usig ECA rules to specify the lifecycles, ad lettig the desiger decide whether to use a state machie paradigm or somethig else for lifecycle of artifacts i a particular BOM. Further, the distictio betwee lifecycle ad associatio is fuzzy i some variatios of BALSA the lifecycle might be extremely detailed, i essece ecompassig all aspects of the associatio level. The choice amog the differet paradigms i costructig a BALSA workflow model will deped o the iteded areas of applicatio Overview of Desig Methodology The desig methodology is firmly cetered o the data beig maipulated as a busiess is maaged. Data-ceteredess is specifically reflected i two desig priciples. Oe is the data first priciple, which demads that at each step, data cosideratio, specificatio, ad desig should precede that of other compoets. The other is the data cetered priciple, which suggests that the specificatio ad desig of tasks ad workflow should be formulated usig the data desig obtaied at each step. Figure 2 summarizes the methodology for busiess process desig. The desig methodology cosists of four major steps: (1) busiess artifact discovery, (2) busiess operatios modelig, ad (3) coceptual workflow desig, ad (4) workflow realizatio. The first two steps aim at formulatig a BOM as a logical specificatio of the busiess operatios meaigful to busiess stakeholders, ad with sufficiet details to allow techical aalysis ad verificatio. The BOM provides a basis for system implemetatio. The last two steps focus o traslatig the BOM ito a executable compositio of services ad sub-systems that faithfully realizes the BOM, i the sese that the executio of the uderlyig workflow correspods to the itetios expressed usig the ECA rules i the BOM. We ow cosider the methodology Data-Cetric Desig Methodology STEP 1: Busiess Artifacts Discovery (a) Idetify critical artifacts for the busiess process (b) Discover key stages of artifacts life cycles from the sceario-based requiremets STEP 2: Desig of Busiess Operatios Model (BOM) (a) Logical desig of artifact schemas (b) Specify services for artifacts eeded for movig artifacts through the life-cycles (c) Develop ECA rules that eable artifacts progress i their life cycles STEP 3: Desig of Coceptual Flow Diagram STEP 4: Workflow Realizatio Figure 2: Desig Methodology at a Glace i more detail. The goal of Step 1 is to develop a high level specificatio of the busiess operatios through discoverig key artifacts ad importat stages i their life cycles. Idetifyig artifacts requires a uderstadig of the whole busiess process, how data are chaged ad shared through the process, ad what data hold critical busiess process iformatio. This is doe through a combiatio of top-dow aalysis ad by examiig typical scearios (ormal busiess cases ad exceptioal cases). Example scearios could iclude, e.g., approvig a qualified loa applicatio, cacellatio of a existig applicatio, situatios whe credit

7 checkig is uecessary. A sceario does ot have to be complete. Scearios are useful as they are cocrete examples of what should happe uder some circumstace ad how. Step 1(b) is to discover ad develop scearios. Based o the top-dow aalysis ad scearios, i Step 1(b) importat busiess stages are formulated ad the the processig costraits o artifacts from the scearios are sythesized to form a artifact life cycle represetig possible ways for artifacts to complete i the busiess process. Oe possible form of represetig a artifact life cycle is a directed graph with odes represetig stages ad edges reflectig the sequecig requiremets. Each graph defies a life cycle state machie. It is iterestig to ote that the machie is i may cases a abstractio of busiess processes i which hardcopy documets move betwee places. I Step 2, the prelimiary desig produced i Step 1 provides the basic skeleto aroud which the BOM ca be costructed. I particular, Step 2(a) focuses o data desig of artifacts; i particular, the details of the artifact schemas are specified usig ER diagrams, which provide a atural framework for specifyig these desigs at a appropriate level of detail. I Step 2(b), the busiess activities are examied with respect to the logical artifact schemas. Usig the life cycle state machies to provide a macro-structure, abstract services are developed for the various busiess activities which operate o the artifacts. Fially i step 2(c) the associatios betwee the services ad the artifacts are specified. Steps 3 ad 4 start from the BOM developed i Step 2 with the goal of obtaiig a operatioal workflow system. This chapter is focused o workflow realizatios for which there is a lack of cetral cotrol, with compoets (artifacts ad services) distributed both geographically ad admiistratively. This is motivated by the icreasig tred for outsourcig ad globalizatio as eabled by the iteret. For this cotext, a coceptual flow diagram is first developed i Step 3 that describes globally how differet data ad service compoets should be coordiated to fulfill the busiess operatioal requiremets as specified i the BOM. The coceptual flow diagram ca be viewed as aother variat of the BALSA framework, i which the associatios betwee services ad artifacts are procedural i ature. I the methodology, the coceptual flow diagram is further modified to satisfy the service behavioral costraits, ad optimized accordig to performace metrics. I Step 4, idividual compoets as well as the workflow are tured ito software systems with less or clear depedecy. 3. ILLUSTRATION OF THE DESIGN METHODOLOGY This sectio will illustrate the key elemets of the data-cetric desig methodology usig a example from the IT service provider busiess, called Distributed Eterprise Services (DES). First the example is described, after which three subsectios discuss steps 1, 2, ad 3 (respectively) of the data-cetric desig methodology outlied i Sectio 2. The DES example focuses o a IT service provider that provides IT services to oe or more eterprises, each of which comprise a large umber of geographically distributed small sites. To avoid cofusio, whe it is ot clear from the cotext we shall refer to the IT services i the DES example as DES services, ad refer to the services used to maage the busiess operatios of the IT service provider as BOM services. I the DES example, provided DES services iclude IT provisioig, istallatio, ad maiteace as well as geeral support. Typical examples for small sites are idividual hotels that are part of a larger chai, or fast food restaurats that are part of a frachise. The IT service - 7 -

8 Backgroud Artifacts Customer Site 1 Vedor 1 m Cofiguratio Artifacts Offered DES Service 1 Geeric Task 1 1 Executio Artifacts Schedule (for Offered DES Service) 1 Vedor Task Figure 3: Key artifacts for DES example, ad primary relatioships betwee them provider typically sigs a cotract with a give chai or frachise corporatio, which determies the service level agreemets (SLAs) for each request for a give DES service. For example, a hotel corporatio might sig a cotract with the IT service provider that allows the provider to perform ay kid of IT systems-related services at idividual hotel sites. The DES services provided at the sites may be performed by the IT service provider themselves or by oe or more sub-cotracted vedors, the latter beig rather typical due to the highly distributed ature of the problem Busiess Artifact Discovery for DES I maagig the busiess operatios of a IT service provider of Distributed Eterprise Services, the artifact-cetered approach focuses o the key busiess etities that keep track of how the busiess (i this case the IT service provider) reaches its operatioal goals. The first step of the desig methodology is to idetify, at a high level, these etities, alog with the key stages of their life-cycle. The process used is typically a combiatio of top-dow cosideratio alog with sceario-based requiremets gatherig. Scearios are ofte easy for the busiess stakeholders to create ad uderstad, ad should iclude both suy day ad exceptioal cases. The mai operatioal goal i DES is the completio of a (possibly complex) DES service or istallatio at a site. The key kid of artifact that measures progress towards the operatio goal for this case is called a Schedule artifact. It cotais the plaed ad actual cotet of the istallatio project pla, icludig ay mid-stream modificatios to the pla ad the workig documets trasferred betwee tasks as part of the executio. Note that the term schedule for this busiess case was derived from the fact that a outlie project pla is geerally attached as a schedule to the cotract statemet of work (SOW). A secod importat class of artifacts is called Vedor Task. Each artifact i this class correspods to a idividual (DES) task to be performed, by the IT service provider or oe of its sub-cotractors, as part of a overall schedule. I geeral a sigle Schedule artifact will refer to several Vedor Task artifacts. Figure 3 shows at a high level the key artifacts for the DES example. Show o the righthad side are the two artifacts already described, which are used primarily durig the executio of DES services. I the middle of the diagram are two artifact classes used durig the cofiguratio or set-up of a DES service. Specifically, the Offered DES Service artifact class holds templates for the differet kids of DES services that ca be provided. I geeral, a actual Schedule artifact will be created by startig with a Offered DES Service artifact ad the istatiatig various compoets of it. Similarly, the Geeric Task artifact class holds descriptios of (DES) tasks that are available to the IT service provider, icludig iformatio o the vedors that provide them ad the geographic regios for which they are available. Fially, o the left-had side are some key artifact classes that provide o-goig backgroud iformatio, icludig about the Customers of the IT service provider, alog with the Sites that those - 8 -

9 customers have, ad also about the Vedors that the IT service provider uses as sub-cotractors. It should be emphasized that a Offered DES Service artifact will iclude data that is essetially a high-level script or program, which will be referred to by the BOM services that work o idividual Schedule artifacts. A Schedule artifact, i tur, will also essetially hold a script that is iterpreted durig the secod phase of the executio of the BOM. This gives some idicatio of the richess of data that a artifact might hold, ad how that data might be used. As suggested above, the amig of artifacts is typically domai specific. The discovery of artifacts is usually a process that ivolves discussios with busiess stakeholders ad subject matter experts (SMEs). The focus i these discussios is ot o the BOM services executed to ru the busiess, but rather o the etities that are used to maage the busiess operatios. This icludes idetifyig the key iformatio related to these etities ad also the high-level stages of their lifecycles. Figure 4 illustrates the high-level lifecycles for artifacts from the Schedule ad Vedor Task classes. I BALSA basic, the highlevel lifecycle of artifacts is specified usig fiite-state machies, typically with coditios o the trasitios. Each state of the machie correspods to a stage i the lifecycle of the artifact; these stages typically correspod to busiess-relevat phases i the overall artifact lifecycle. I Figure 4, the stages are show usig rouded rectagles with solid lie Plaig Schedule_ plaig (& Refiemet) Plaig Task_ plaig (& refiemet Schedule_ approvals Task_ approvals Executio Executio (& mior revisio) Reapproval (a) Lifecycle of artifacts i class Schedule Executio (& mior revisio) Major_ revisio (b) Lifecycle of artifacts i class Vedor Task Figure 4: Represetative artifact type lifecycles Archived Archived boudaries. The dashed-lie rectagles are icluded to suggest how the fiite state machies exteded to icorporate hierarchy. Although ot formally icluded ito BALSA basic, these dashed-lie states might be to provide a mechaism that permits substitutio of oe workflow compoet by aother workflow compoet (e.g., by swappig the cotets of a high-level state such as Plaig for aother versio of it). This mechaism might be useful durig BOM evolutios, or if a geeric BOM is used to represet a global busiess, ad specializatios of it are used as the BOMs for differet regios. As show i Figure 4, there are six stages i the lifecycle of a Schedule artifact, ad four i the lifecycle of a Vedor Task artifact. The Schedule_ plaig phase icludes BOM services that select ad the flesh out a Offered DES Service artifact, to create a Schedule artifact for a give IT service egagemet. At some poit durig executio the schedule may move ito the Schedule_approvals stage, where various maagemet approvals (ad perhaps exteral approvals from cliet ad/or govermet) may be obtaied. The coditio goverig this trasitio might state that all geeric tasks eeded to fulfill the schedule have bee associated to a specific Vedor Task artifact, with all dates ad task-level govermet approvals established

10 Oce i the Schedule_approvals stage, if the approvals are successful, the schedule moves oto the Executio stage; otherwise it goes back to Schedule_plaig. (A alterative sematics would be to allow some stages to operate i parallel, i a cotrolled maer. This is ot studied here, but is certaily a importat topic for future ivestigatio.) Mior pla revisios may occur i the Executio phase, but if more sigificat revisios are eeded the the istallatio will pass ito the Major_revisio ad Re-approval stages. Evetually, hopefully after a successful egagemet, the schedule is Archived. The lifecycle of Vedor Task artifacts is similar. Not show for either artifact class are trasitios used if a schedule or vedor task is aborted (ad archived) before successful completio. As a geeral desig priciple, the coditios o trasitios betwee artifact stages should be focused o the miimal busiess requiremets eeded to pass betwee them. As will be see below, additioal coditios goverig whe a artifact ca pass from oe stage to aother ca be icorporated at the level of associatios. This provides rich flexibility i terms of specializig the basic artifact lifecycle to fit with a variety of cotexts, e.g., resultig from govermet regulatios i differet regios, DES offerigs provided at differet budget poits or for differet classes of customers, or eve occasioal sales promotios or other special offerigs. As oted i Sectio 2.1, artifacts may have differet life expectacies. I the DES example, the Schedule ad Vedor Task artifacts may have lives of a moth to a year, but have a defiite begiig, middle, ad ed. The artifacts of other classes show will typically have loger lives, but may idividually be retired as they become obsolete. Allowig for artifact classes with these varyig life expectaces provides cosiderable flexibility while keepig the umber of costructs i the BALSA workflow framework to a miimum Desig of the Busiess Operatios Model for DES Creatig a Busiess Operatios Model (BOM) from the high-level artifact class ad lifecycle specificatios ivolves three primary steps, amely detailed specificatio at the logical level of: (a) the artifact iformatio models ad macro-level lifecycles, (b) the BOM services that will help move artifacts through their lifecycles, ad (c) the ECA rules that associate the services to the artifact classes. These three steps typically occur simultaeously, although coceptually the artifact desig leads aturally to the service desig, ad from there to the associatio step. This subsectio cosiders each of these steps i tur, ad also provides some commets o the operatioal sematics of the ECA rules used here. Specificatio of Artifact Iformatio Models ad Lifecycles. As just metioed, a primary step i the process of desigig the BOM is to created specificatios for the key artifacts, icludig both their iformatio models ad macro-level lifecycles. The discussio here will focus oly o the iformatio models for key artifacts, because represetative macro-level lifecycles for them have already bee described i Sectio 3.1 (see Figure 4). Figure 5 shows portios of the iformatio models for four of the key artifacts i the DES example. Etity-Relatioship (ER) diagrams provide a coveiet framework for specifyig the iformatio models, ad tools are available to map such diagrams ito relatioal database schemas. Each ER diagram is cetered aroud its key artifact class; i essece all of the iformatio held by the ER schema ca be thought of as providig iformatio about idividual artifacts i this class. While the iformatio models use ER paradigms for artifact classes

11 discussed here, the artifacts might be physically stored usig, e.g., relatioal or XML-based databases. I these ER diagrams the focus is o the curret values that ca be associated with a artifact. Oe typically thiks of a artifact iformatio model i terms of providig storage for a variety of attributes of the artifact, e.g., for a Schedule artifact attributes such as associated the curret stage, start-/ed-dates, ad refereces to associated Vedor Tasks, etc. I geeral, it is also useful to retai a log of values that have bee overwritte over the course of a artifact s lifecycle. Whe a artifact is created, may of its attributes have udefied or ull values. As the artifact progresses through its lifecycle, the attributes may be assiged values, i.e., become defied, they may be overwritte (or i the case of set- or list-valued attributes they may obtai or lose elemets). I additio, some attribute values may become ivalidated. Ituitively, a service (task) might switch a attribute value to ivalid as a way to idicate the existig value violates a costrait ad should be repaired by some subsequet service ivocatio. This might arise, for example, because the start_date of oe vedor task t 1 should be after the ed_date of some other vedor task t 2, but the ed_date of t 2 has just be re-assiged to a value which is after the assiged start_date of t 1. The use of these three types of values (udefied, ivalidated, defied) is optioal although coveiet i may practical settigs. Offered DES Service supplies m Vedor optioal? Offered DES Service icludes (a) Offered DES service icludes m requires m Govt. Approval m Geeric Task Geeric Task uses (c) Geeric task m Equipmet Type offered_serv_id stage descriptio typical_ duratio precedece m k ge_task_id stage base_ cost typical_ duratio ivolves m Labor Type Offered DES Service Site 1 based_ o serves 1 optimality_ factor o_vedor_ available Schedule m icludes k Geeric Task (b) Schedule requires (d) Vedor Task Vedor Task schedule_id stage plaed_ start_date plaed_ ed_date revisio_ checklist approved_ for_exec 1 exec_status precedece m vedor_ task_id stage Schedule icludes Vedor Task cust_ad_ 1 site_ifo plaed_ start_date plaed_ ed_date status supplied_by 1 Vedor 1 Govt. Approval 1 uses Equipmet Order 1 uses Labor Spec Figure 5: Details of portios of ER diagrams for selected artifacts i DES example Key aspects of the four ER schemas i Figure 5 are ow highlighted. Not all attributes for the artifacts are show; rather the portios of the schemas show are to suggest what might be icluded. The Offered DES Service schema provides scalar attributes for a ID, for the curret stage the artifact is i, for a descriptio, ad for iformatio o typical_duratio of the give offered DES service. Each offered DES service may also cotai a umber of Geeric Task

12 artifacts these would correspod to the idividual tasks that must be performed durig the course of the offered service. The rectagle eclosig Geeric Task here is show as dashed, to idicate that this etity type is defied elsewhere (amely i the schema for the Geeric Task artifact class). The Boolea attribute optioal? ca be used to idicate some level of possible variatio betwee istaces (i.e., schedules) of a Offered DES Service. Precedece betwee the geeric tasks is also icluded. For the example described here, a simple otio of precedece is used, based o start- ad ed-dates of the tasks, but richer forms of precedece could be used. The Schedule schema icludes various scalar attributes. The revisio_checklist provides a structured value that is used to keep track of the revisios of the schedule that must be performed; this is useful as idividual vedor tasks get modified, which may have impact that ripples to other, already plaed vedor tasks. A schedule also has specific scalar values for approved_for_exec(utio) ad exec(utio)_status, which ca be used both to record how a artifact is progressig, ad i the evets ad coditios of ECA rules. The icludes relatioship is used to coect a schedule to the geeric tasks which must be performed, ad as the plaig process progresses, the specific vedor tasks that will be used to istatiate those geeric tasks. The schemas for Geeric Task ad Vedor Task should be self-explaatory. I those schemas several of the subordiate etity types are show with solid rectagles, sice i this example artifact classes are ot associated with them. There are two primary cosideratios i desigig the artifact schemas. The first is drive by the basic axiom of the data-drive approach to workflow, specifically that a artifact A should hold, at ay give time, all of the busiess-relevat iformatio about A. The secod cosideratio is that the logs of artifact istace histories should eable rich ad flexible moitorig of curret workflow performace, ad aalysis of past workflow performace. The artifact-cetric approach leds itself to this, because the artifact life-cycles typically cross multiple sub-orgaizatios (or orgaizatios, i the case of out-sourcig). Eve if the data for a artifact is physically stored i differet places, the artifact schemas provide a uifyig view agaist which to defie Key Performace Idicators ad dashboards, ad to perform both systematic ad ad hoc data miig ad reportig. Although ot at the same level as the artifact attributes icluded ito the busiess operatios model, it may be useful to icorporate ito the artifact schemas additioal attributes to store iformatio about the proveace of the artifacts, that is, how ad why they evolved as they did. This could iclude iformatio about which services were used ad details about how ad why they were ivoked. Specificatio of BOM services. The discussio ow turs to the secod mai activity i specifyig a BOM: the specificatio of the BOM services that will help move artifacts through their life-cycles. If the artifact schemas are defied well, it should be relatively straightforward to idetify BOM services that correspod to both (a) atural busiess activities, ad (b) update coheret groups of artifacts ad attributes. I the discussio here, each BOM service is associated with a primary artifact class; the actio of the service will be focused o a sigle artifact of this class (icludig possibly creatio of a ew artifact of this class), ad the service might read or write attributes of other artifacts (from the same ad/or other artifact classes). Recall that i the BALSA basic workflow model, the family of BOM services for a applicatio domai is typically specified i a maer largely idepedet of the aticipated sequecig of those services. I geeral, oe might have a large library, or soup, of BOM services associated with a family of artifact class schemas. For differet realizatios of a

13 applicatio domai (e.g., for differet IT service providers offerig DES) oe might associate differet subsets of this library to the artifact classes. This permits cosiderably more flexibility tha is typical i workflow frameworks that specify the sequecig of services usig exclusively procedural ad/or graph-based formalisms. To illustrate key poits about BOM services ad their specificatio the Schedule ad Vedor Task classes are used. I the DES example there could be over 50 BOM services cetered aroud the processig of artifacts i these classes. The focus here is o the group of BOM services that are relevat whe a schedule is i the Schedule_plaig stage (although some of them might also be used i the Executio ad Major_revisios stages). A small but represetative subset of these BOM services is listed below. create_schedule (Offered DES Service: o, Customer: c, Site: si): This service has the effect of creatig a schedule artifact for o, c, ad si (where si is a site of c). create_vedor_task (Schedule: sch, Geeric Task: g): This service has the effect of creatig a vedor task artifact that will be associated with g i sch. adjust_task_geeral (Vedor task: t, Veder: v, Schedule: sch, list[task, start_date, ed_date]): This service is used to revise ay ad all aspects of a vedor task t durig the Task_plaig stage. The vedor task serves as the primary artifact for this service ad the followig oes; the other artifacts that are used as iput are all reachable from the primary artifact. The list of tasks with start- ad ed-dates is iteded to hold all tasks that are immediate successors of t accordig to sch. adjust_task_date (Vedor task: t, Veder: v, Schedule: sch, list[task, start_date, ed_date]): This service is used to revise the date-related attributes of vedor task t (ad possibly touch other artifacts that are impacted, e.g., by ivalidatig attributes of depedet vedor tasks ad updatig the revisio_checklist attribute of the schedule sch that t belogs to). This service ad the ext two, while somewhat redudat with adjust_task_geeral, are icluded to illustrate how services might overlap i their fuctio. Also, these three services might be executed i parallel, whereas if adjust_task_geeral is workig o a vedor task t, it will typically block the other services from maipulatig t. request_govt_approval (Vedor task: t, Veder: v, Schedule: sch): This service is used to create ad trasmit a request for oe or several govermet approvals for a vedor task. adjust_task_govt (Vedor task: t, Veder: v, Schedule: sch, list[task, start_date, ed_date]): This service is used for maipulatio of a task whe iformatio is received about pedig govermet approvals. I the BALSA basic workflow model, at the level of the Busiess Operatios Model, BOM services are specified usig four key properties, amely, Iput artifacts ad attributes, Output artifacts ad attributes, Pre-coditios, ad (Coditioal) Effects. These combie to form the IOPE (proouced I-O-P-E) specificatio of the service. The focus here o the logical properties of a service allows for a sigificat separatio of cocers at the BOM level the focus is o the logical properties ad effects of ivokig a service, whereas at the Realizatio level the focus ca be o the more procedural ad implemetatio aspects of a

14 service. This follows the spirit of research i the past few years o OWL-S ad more geerally, Sematic Web Services. It allows for rich forms of automatio i the specificatio ad realizatio of workflows. For example, sythesis algorithms have bee developed for specialized settigs, to automatically create compositios of services that satisfy high-level busiess goals (expressed usig logical formulas) ad govermet regulatios (also expressed as logical formulas). Also, aalysis algorithms, which ca verify properties of workflows such as reachability or costrait satisfactio, are sometimes developed more easily if services ad other compoets are specified usig high-level logical properties rather tha lower-level procedural oes. The use of logical specificatio of BOM services ca also be viewed as providig a partitio of specificatio iformatio: aalysis of a BOM at the macro level uses the logical specificatio of the BOM services, ad the aalysis of idividual BOM services to check whether their detailed specificatio complies with the IOPE specificatio ca occur separately. I a IOPE specificatio of a BOM service, the iput ad output artifacts ad attributes idetify, respectively, the data values that will be read ad that may be updated by the service. The pre-coditios must be satisfied before the service ca be ivoked. As a desig guidelie it is geerally recommeded to keep the pre-coditios as miimal as possible, focusig primarily o coditios eeded by the service i coectio with the specific artifacts. Additioal iformatio about whe the service ca be applied, which is specific to a give BOM desig cotext, may be icorporated by the ECA rules for that domai. Fially, the coditioal effects provide iformatio about the possible effects that applyig the service will have. The IOPE specificatios are ow described for two of the BOM services, amely, create_schedule ad adjust_vedor_task. The descriptios are provided i Eglish, although i practice a formal otatio would be used. The create_schedule service has a IOPE specificatio with the followig properties. Iputs: o A Offered DES Service artifact o, ad specifically the listig of used Geeric Tasks, alog with whether they are optioal, ad iformatio about the Precedece relatioships betwee them. o A Customer artifact c, ad specifically iformatio about specific requiremets for c, e.g., levels of quality ad service to be followed; implicatios aroud govermet regulatios; etc. o A Site artifact si for c, ad specifically iformatio about specific requiremets for si, icludig govermet-related issues based o locatio, muicipality, state; iformatio useful i determiig vedor availability, shippig costs, etc. Outputs: o A ew Schedule artifact sch. The data writte will iclude attributes schedule_id, stage, plaed_start_date, ad the Geeric Task portio of the icludes relatioship. (The cocrete Vedor Task values will be filled i by executios of the assig_vedor_task service.) o The Site artifact si is updated to record the fact that a ew Schedule artifact has bee created for si. Pre-coditios o Offered DES Service artifact o must be compatible with the ifrastructure ad eeds of site si

15 Coditioal effect o If true, the sch is i stage Schedule_plaig. o If true, the sch holds a schedule skeleto (i.e., appropriate portios of the relatioship icludes are filled i). o If true, the Site artifact si is updated to reflect the creatio of sch. o If true, the for each Geeric Task artifact g that is required to accomplish o for si for which there is ot at least oe qualified Vedor servig the regio of the Site, the the o_available_vedor flag is set for g. The IOPE specificatio for adjust_task_dates has the followig properties: Iputs: o A Vedor Task artifact t, iformatio about specific requiremets for the customer ad site associated with t s schedule, ad about the curret status of various steps (govermet approvals, equipmet availability, etc.). o A Vedor artifact v, ad specifically iformatio about v s availability, about the cost for re-schedulig the task, etc., for the vedor assiged to perform t. o A Schedule artifact sch, ad specifically iformatio about immediate predecessors ad successors of t i sch. o A list T of triples of form (Task, date, date). Outputs: o Updates to start ad/or ed dates of t. o (Possibly) updates to the revisio_checklist of sch. o (Possibly) updates to the status fields of each Vedor Task artifact t that is a successor of t i sch, if the modificatio to t impacts t, ad ivalidatig the dates of each such artifact. Pre-coditio o Vedor task t is assiged to supplier v. o Vedor task t occurs i Schedule sch. o T is the list of tuples (t, s t, e t ), where t is a task that succeeds t i sch accordig to the Precedece relatioship, ad s t, e t are the start- ad ed-times of t, respectively. Coditioal effects o If true, the the start ad/or ed dates of t may have bee overwritte o If the start date of t is overwritte, the it is after the ed date of each predecessor of t. o If the start or ed date of t is overwritte ad this impacts the timig of ay successor t of t (i.e., ay task occurrig i T), the the dates for t are ivalidated ad the revisio_checklist of sch is updated accordigly. There is a circumscriptio coditio o the sematics associated with coditioal effects. Specifically, i the applicatio of a BOM service each attribute that is ot metioed i the cosequet part of a coditioal effect with coditio that evaluates to true must ot chage its value, ad likewise, the state of a artifact must ot chage uless that is specifically called for by a coditioal effect with coditio that evaluates to true. Oe might expect that the adjust_task_dates should iclude i the pre-coditio a restrictio permittig the service to ru oly if a vedor task s schedule is i stage schedule_plaig,

16 executio, or major_revisio, sice those are the stages where schedules might be modified. However, i the overall desig of the BOM preseted here, this restrictio is icorporated ito the ECA rule that govers whe adjust_task_dates ca be ivoked. I geeral, there are tradeoffs cocerig whether coditios are icluded ito the pre-coditio for a service or the ECA rules that gover whe it ca be ivoked. Oe advatage of keepig a service s pre-coditio miimal is that it allows the service to be used i a broader variety of applicatio domais ad cotexts. Specificatio of ECA rules. The discussio ow turs to the third major phase of specifyig a BOM i BALSA basic, amely, the specificatio of how services are associated to artifacts, or i other words, the specificatio of the micro-level of artifact lifecycles. The model uses Evet- Coditio-Actio (ECA) rules. I geeral these rules have the form if some evet occurs, ad if a coditio is true about the objects that witess the evet occurrece, the take a particular actio. I some cases there are also CA rules i which the evet portio is ot specified; this meas that the rule ca be applied at essetially ay time. The ECA rules used i BALSA basic are focused at the coceptual level of the model; i particular the evets are specified i terms of the BOM services beig ivoked or termiatig; artifacts beig created or modified, or chagig stage; ad operatios-level exteral messages beig received ito the workflow system. The ECA paradigm has bee used i workflow (ad other) cotexts for several decades, ad provides a very flexible mechaism for specifyig system behaviors. O the oe had, it ca be used to faithfully simulate flow-charts ad other highly procedural styles of behavior specificatio. At the other extreme, by exclusively usig CA rules the paradigm ca take o a very declarative style remiiscet of logic programmig ad deductive database systems. Betwee these extremes, ECA ca be used to simulate the paradigms of expert systems ad productio rule systems. Differet macros ca be costructed o top of a ECA basis to make it easy for ruleset creators ad busiess users to thik i terms of the various paradigms just metioed. Further, a hybrid framework ca be costructed o top of the ECA basis, combiig for example a flowchart specificatio for certai stages of a artifact class ad a much more free-form, declarative specificatio for some other stages of the class. BALSA basic focuses o ECA because it provides a miimal set of costructs that ca form the basis for this rich family of variatios for associatig services to artifacts i the data-cetric workflow settig. I the example ECA rules preseted here, a fourth field is icluded. This By field is used to list the properties ad qualificatios of the people who may perform the associated actio. These performers might iclude customer service represetatives, clerks, maagers, etc. This field is icluded here primarily to provide a brief illustratio of how iformatio about the process users ad their participatio ca be associated to artifact lifecycles. I a full solutio, it will be useful to iclude a substatial meta-model for represetig all of the people that might be ivolved with a BOM, ad the ways that they might iteract with it. I additio to the actual performers, it will be useful to model teams of users, experts that provide cosultig advice to the people actually performig the BOM services, etc. The basic buildig blocks for the ECA rules used here are as follows. Evets: A attribute value just assiged A attribute value just assiged ad satisfies a predicate ivolvig other curret artifacts

17 ad attribute values A artifact has just moved ito a stage A service has bee lauched or completed o a artifact A icomig message (e.g., from a govermet agecy) A performer request Coditios Formulas writte i first-order logic (or, more-or-less equivaletly, a relatioal database query laguage). Typically the coditios come from a targeted subset of first-order logic, such as the quatifier-free fragmet, or the fragmet which does ot permit quatifier alteratios. Actios Ivoke a service Move a artifact to a stage By Roles ad qualificatios eeded by the performer of the actio A small family of represetative ECA rules for the DES example is ow preseted, followed by a discussio of the sematics associated with ECA rules. R1: Iitiate schedule evet request by performer p to create a schedule istace for Offered DES Service artifact o, Customer artifact c, ad Site artifact si coditio the appropriate o-disclosure agreemets (NDAs) are i place for c actio ivoke create_schedule(o, c, si) by performer p where offer_maager i role(p) ad qualificatio(p, o, regio: si.regio) 5 The above rule is used to create a ew schedule. It is triggered whe a performer requests this. Note that the request icludes the offered DES service, the customer, ad the customer site where the service will be give. The qualificatio fuctio is used i this rule ad below as a mechaism for idicatig the skill set eeded by the performer that will actually perform the service beig ivoked. For these examples the values of qualificatio rage from 1 (ot very qualified) to 10 (a guru). The iput argumet si.regio illustrates how we use the. otatio to avigate through oe or more artifacts to fid values of iterest. This i-place fuctio is viewed as beig polymorphic depedig o the umber ad types of the iput argumets it will evaluate appropriately. This fuctio could be supported by a family of relatioal database tables. R2: Iitiate vedor task coditio for Schedule artifact sch ad Geeric task artifact g cotaied i sch, each predecessor of g i sch has a associated vedor task artifact with defied start ad ed dates; sch is i stage Schedule_plaig or Major_revisio; ad g does ot have a associated vedor task

18 actio by ivoke create_vedor_task(s,g) performer p where qualificatio(p, sch.offered_service, g) 2 ad qualificatio(p, g, sch.customer.site.regio) 6. Note that this rule has o triggerig evet, which meas that the rule ca be fired at essetially ay time that the coditio becomes true. I practice, the rule might be triggered whe the fial predecessor of g i sch obtais defied start- ad ed-dates. I the example, the create_vedor_task will, amog other thigs, set the iteded start ad ed dates for the created vedor task. This is why the predecessor tasks of g i sch must already have dates assiged. Here the performer must be somewhat kowledgeable about the overall offered DES service that uderlies schedule sch, ad also well-qualified o the geeric task g for the regio where sch will be istalled. There may be other rules that eable ivocatio of create_vedor_task, e.g., if a performer requests it. R3: Adjust vedor task dates coditio for Vedor Task artifact t occurrig i Schedule artifact sch, sch is i stage Schedule_plaig, Executio or Major_revisio; the start- ad/or eddate of t is ivalid; ad each predecessor of t i schedule sch (accordig to the precedece relatioship i sch) has defied start ad ed dates. actio ivoke adjust_task_dates(t, v, sch, T), where v is the vedor supplyig t, ad T is a list of triples holdig, for each task t that succeeds t i sch, the triple (t, s, e) where s, e are the start- ad ed-times of t, respectively. by performer p where qualificatio(p, o, g) 4, where o is the offered DES service associated with sch, ad qualificatio(p, g, regio: sch.customer.site.regio) 8. Performig the service adjust_task_dates uder this rule requires more qualificatios tha performig create_vedor_task. This rule ca be fired wheever the dates of a vedor task are ivalid. R4: Request task govermet approval coditio for Vedor task artifact t occurrig i schedule sch, sch is i stage Schedule_approvals or Re_approval; if govermet approval is eeded for t ad ot yet requested; ad the required values for t are defied. actio ivoke request_govt_approval(t, v, sch), where v is the vedor providig t. by performer p where qualificatio(p, sch.offered_service, g) 2 ad qualificatio(p, g, t.schedule.customer.site.regio, aspect: govermet ) 6. R5: Modify task govermet iformatio evet receive govermet respose to a request approval of Vedor task artifact t which is owed by schedule sch. coditio sch is i stage Schedule_approvals or Re_approval. actio ivoke adjust_task_govt(t, v, sch, T), where v is the vedor supplyig t, sch is the schedule that t participates i, ad T is a list of triples holdig,

19 by for each task t that succeeds t i sch, the triple (t, s, e) where s, e are the start- ad ed-times of t, respectively. performer p where qualificatio(p, sch.offered_service, g) 2 ad ad qualificatio(p, g, regio: t.schedule.customer.site.regio, aspect: govermet ) 6. The above two rules focus o govermet approvals for vedor tasks. R6: Lauch schedule approval coditio for Schedule artifact sch, sch is i stage Schedule_plaig; sch.revisio_checklist is empty; ad for each Geeric task artifact g of sch, g has a associated Vedor task artifact t which has t.status = ready_for_executio. actio move_to(sch, Schedule_approvals) by automatic The above rule permits a schedule to move from the Schedule_plaig stage to the Schedule_approvals stage. This illustrates how the set of ECA rules associated with a applicatio domai ca specialize the coditios about stage trasitios that are icorporated ito the fiite state machie for the macro-level life-cycle of a artifact. Note the use of a uiversal quatificatio ( for each Geeric task artifact g ), which i this case is bouded to rage over artifacts associated with sch. R7: Lauch schedule executio evet for Schedule artifact sch, sch.approved_for_exec := true coditio true actio move_to(sch, Executio) by automatic The fial example rule permits a schedule to move to the Executio stage. This is triggered whe the attribute approved_for_exec is set to true. This illustrates that there ca be a close relatioship betwee attribute values ad stages i the macro-level lifecycle. Ideed, i a formal sese the state machie for stages ca be simulated by extra attributes ad some ECA rules. However, the stages ad state machie are explicitly icorporated ito the model to make BALSA basic BOMs more readily uderstood by busiess maagers, ad to permit the specificatio of a ituitive structure for lifecycles at the macro level. Executio Sematics of ECA rules. A simple, represetative, logical executio sematics for ECA-based rules is ow described. We emphasize that these are at the logical rather tha implemetatio level may optimizatios ca be icorporated whe implemetig a give ruleset while evertheless obeyig the logical sematics. The logical sematics is based o the followig cocepts. 1) No-determiism: I the sematics preseted here, o-determiism is permitted i two ways. The first cocers the order that eligible rules are fired. Thus, if more the oe rule is

20 triggered by the same evet, or more geerally, if more tha oe rule is eligible for firig at a give poit, the the system will pick oe of them o-determiistically for executio. This kid of assumptio is commo i declarative frameworks; oce a desiger is used to the odetermiism it ca provide more flexibility i the desig of a ECA ruleset. Alteratively, a ECA ruleset might icorporate mechaisms that restrict the o-determiism by requirig that rules happe i a more determiistic fashio (e.g., by addig coditios that help to arrow the set of rules eligible at ay give poit i time). The o-determiism offers may opportuities for optimizatio i the implemetatio. Importatly, a implemetatio that eables ay oe of the o-determiistically specified executios of the ECA ruleset is cosidered to be valid; the implemetatio does ot itself have to support the o-determiism or eable all possible valid executio sequeces. The assumptio of o-determiism is also quite useful i coectio with formal verificatio ad automated costructio of ECA rulesets. The secod form of odetermiism is discussed i item (3) below. 2) Rule triggerig: This applies to rules with explicitly specified evet. Such a rule is triggered if the evet becomes true for some particular bidig (assigmet) β of the variables occurrig i the evet. The rule ca be triggered oly oce for a give evet ad bidig. 3) Rule firig: A rule is cosidered to be eligible for a give variable bidig β if its evet has bee triggered with bidig β, or if it has o evet (i which case β is empty). The rule firig for a eligible rule has two phases. First, the coditio of the rule is tested. The coditio is cosidered to be true if there is some bidig β which exteds β to the uboud variables occurrig i the coditio, so that the coditio is true uder β. This choice of β is the secod form of o-determiism i the logical sematics for ECA ruleset executio. For a give eligible rule oly oe of the bidigs β that makes the coditio true is cosidered whe firig the rule. If a appropriate performer is ot available to perform the actio, the the actio is parked util a performer becomes available. 4) Heap of eligible rules: As suggested i poit (1) above, a uordered heap is maitaied that holds eligible rules. Each time a rule evet for some bidig, the rule with bidig is placed o the heap. Also, wheever a rule without evet has a bidig for which the coditio is true, it is put o the heap with that bidig. At ay poit i time a rule with bidig i the heap ca be selected ad fired. 5) No starvatio: The actual processig of the rules caot idefiitely starve a eligible rule from firig. 6) Serializability: While the actual processig of the rules ad their actio might be iterleaved ad/or parallel, the et effect of the firig of rules must be equivalet to some serial firig of the rules with the same bidigs. (This is aalogous to the serializability requiremet typically placed o sets of updates to a database.) With ay ECA-based sematics there are several issues that must be cosidered. At the logical level, these iclude the followig. Reachability: Give a set of rules, is a give predicate (e.g., a certai stage i the macro lifecycle, a attribute reachig a give value, etc.) reachable through firigs of the rules? Deadlock: Ca the system reach a deadlock? How ca all deadlocks be preveted? Termiatio: For each artifact type with a bouded lifecycle, does each executio of the rules for artifacts of this type ed i a fiite umber of steps?