1 / 34

Rick Hull hull@us.ibm

Artifacts in Business Processes: Helping Workflow become Declarative -- or –- New Model  New Questions. Rick Hull hull@us.ibm.com.

sunee
Download Presentation

Rick Hull hull@us.ibm

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Artifacts in Business Processes: Helping Workflow become Declarative -- or –- New Model  New Questions Rick Hull hull@us.ibm.com Drawing on discussions and collaborations with Kumar Bhaskaran, Kamal Bhattacharya, Nathan Caswell, David Cohn, Christian Fritz, Santhosh Kumeran, Rong (Emily) Liu, Anil Nigem, Jianwen Su, Fred Wu, and others CAISE keynote, 20 June 2008

  2. Widely used approach to workflow design Process Modeling • Data and business objects are typically an afterthought • Hard to evolve the workflow for new requirements • Hard to re-use pieces of workflows to make new ones • Hard to create a generic workflow with various specialization (e.g., for different regions) • Hard to manage workflows distributed across organizations Data Modeling Business Logic Ad hoc implementation Workflow System (flow mgmt, services, databases, resources, …) System in Operation We propose to re-think workflow … … at its very foundations

  3. The notion of “business artifact” • In practice, most business processes are centered around key data objects which evolve over time, e.g., • Sales invoice, book order, shopping cart • Insurance claim • Trouble ticket in IT support • Monthly sales report • Warehouse inventory • Log of experiments in search of a new drug • These “business artifacts” have a macro-level life-cycle • Shared across all artifacts of a given type • Artifacts typically persist across much or all of the workflow • Workflow tasks typically focus on updating one or two artifacts, possibly reading from others Artifacts + macro life-cycle • provide a natural skeleton for workflows • which is relatively stable across evolution

  4. Data Modeling (Business)Artifacts Macro Life-cycles Services Principled physical realization Workflow Implementation (flow mgmt, services, databases, resources, …) Artifact-centric Workflow in a nutshell Associations Process Modeling (structured around artifacts, spread across Services and Associations) We obtain different workflow models by varying • the data model underlying artifact schemas • how services are specified, and • how associations are made

  5. Radically Simplified tools Artifact-centric approach forms basis of a current and growing IBM toolkit and professional services offering • Methodology • Artifact-centric modeling • Transformation to UML • Mapping to procedural representation • Code Generation • Toolkit • WBM, RSA, WID • WBM2UML transform • UML2SOA transform • Applications • Insurance • Retail • Procurement • Pharmaceutical • Finance • . . . Implementation (~40% efficiency improvement) Significant Revenue Impact Concepts and Design • This was achieved using an artifact-centric model with a very procedural way of associating services to tasks • We believe that shifting to declarative associations can bring rich benefits

  6. Outline • Artifact-centric workflow models • Research challenges and directions • Conclusions

  7. Running Example:Distributed Enterprise Services (DES) • IT service provider • Providing IT services to a large enterprise • Which has many “small sites” • E.g., fast foods, hotels, car rentals • IT services • Typical involve several or many steps • Steps might be performed by sub-contractors (or “vendors”) • Challenge: Find a systematic way to manage the different service offerings • May have varying number of tasks • May have regional differences (e.g., regulations) • May deal with numerous vendors for the same task

  8. These artifacts essentially hold small programs Background Artifacts Execution Artifacts Configuration Artifacts Customer OfferedService Schedule (for Service Order) 1 n 1 1 n 1 Focus in next few slides n 1 Site n n Vendor Task Generic Task Vendor 1 n n m Artifacts can hold many forms of data . . . Key artifacts in DES

  9. Execution Planning Execution (& minor revision) Schedule_ planning (& Refinement) Schedule_ approvals Archived Major_ revision Re-approval Planning Execution (& minor revision) Task_ planning (& refinement Task_ approvals Archived Macro Life-cycles for Schedule and Vendor Task Schedule • Conditions permitted on transitions • Typically several services applied during each “stage” • Hierarchical aspect permits scaling and one form of substitution Vendor Task

  10. offered_serv_ID Offered Service description typical_ duration n n includes precedence optional? m k m Generic Task Going deeper into Offered Service • ER as well-known, convenient way to represent structure of data • Physical implementation can be relational or other • Can support different views for different kinds of stake-holders • Can use other models – XML, nested relation, name/value pairs Although using the ER model, we usually refer to the data values associate to an artifact as “attributes” of the artifact

  11. schedule_ID n 1 Offered Service based_ on planned_ start_date Schedule planned_ end_date serves Site n 1 revision_ checklist m approved_ for_exec 1 includes optimality_ factor precedence exec_status n k m n no_vendor_ available Generic Task Vendor Task Going deeper into Schedule • revision_checklist used to keep track of the work needed to finish the planning of this schedule

  12. Data Modeling We think in terms of a “soup” of services • For example: • create_schedule ( Offered Service, Cust, Site ) • create_vendor_task ( Schedule, Generic Task) • adjust_task_general ( Vendor Task ) • adjust_task_dates ( Vendor Task ) • request_task_govt_approvals ( Vendor Task ) • . . . Process Modeling (structured around artifacts) By starting with a view of services as separate from their sequencing, we have better chance to understand their intrinsic properties

  13. Service specifications 1:à la Semantic Web Services, OWL-S “IOPE”s • Input parameters (artifacts and attributes) • Output parameters (artifacts and attributes) • Pre-conditions • (Conditional) Effects Allows to focus on the intention of the service • Actual implementation considered at a lower level

  14. adjust_task_dates specified using IOPE (informal) • Inputs: • Vendor Task artifact t, information about specific requirements for that customer and site, and about the current status of various steps (govt. approvals, equipment availability, etc.). • Vendor artifact v, and specifically information about v’s availability, about the cost for re-scheduling the task, etc. • Schedule artifact s, and specifically information about immediate predecessors and successors of t. • For each Vendor Task artifact t’ that is a descendant of t in s according to the precedence relationship, values of planned start and end dates. • Outputs: • Updates to start and/or end dates of t. • Updates to relevant parts of s concerning start/end dates for t. • (Possibly) updates to the status fields of each Vendor Task artifact that is a descendent of t in s. • (Possibly) update revision_checklist of s • Pre-condition • Task t is assigned to supplier v. • stage(s) = schedule_planning or stage(s) = execution or stage(s) = major_revision • Conditional effects • If true, then the start and/or end dates of t may be overwritten • If the start date of t is overwritten, then it does not conflict with the dates of any predecessor of t. • If the start or end date of t is overwritten and this impacts the timing of any successor t’ of t, then the dates for t’ are invalidated and s.revision_checklist is updated accordingly. Different logics and logic fragments will yield different expressive power, different properties

  15. Service specifications 2:Conditions in a more structured, pictorial representation Vendor Tasks in stage Task_Planning • This is the style supported in IBM’s offering today All preceding tasks have valid dates adjust_task_dates preceding_ tasks successor_tasks Schedule is for on this site Schedule is owner of primary task Schedules in stage Schedule_Planning Sites in stage Stable

  16. Claim Investigation Not Required Decideon Claim ValidateClaim NotifyClaim RecordClaim AnalyzeClaim Created Recorded Investigation Required Analyzed Start RejectClaim ProvideAdd’l Data Review ClaimRejection Data Added Additional Data Needed Review Needed Rejected Accepted Closed Record BenefitPayment Prepare ClaimDischarge OfferBenefit Discharged Benefit Offered • This is the style used in IBM’s offering today Associating Services to Artifacts 1:Procedural • Start with pictorial representation of services • Use states for both macro- and micro-level life-cycle of artifacts • Add triggers so that entry into a state can cause invocation of a service • (If done correctly) this will induce a flow of artifacts through the workflow

  17. Associating Services to Artifacts 2:Event-Condition-Action (ECA) rules • R1: Create new schedule • Event: request by performer p to create a schedule instance for Offered Service artifact o, Customer artifact c, and Site artifact si, where offer_managerin role(p) • Condition: the appropriate non-disclosure agreements (NDAs) are in place for c • Action: invokecreate_schedule(o, c, si) • By: performer p where qualification(p, o, region: si.region) ≥ 5 • R2: Move to schedule approval stage • Condition: for Schedule artifact sch, sch is in stage Schedule_planning, sch.revision_checklist is empty, andfor each Generic task artifact g of sch, g has an associated Vendor task artifact t which has t.status = ready_for_execution. • Action: move_to(sch, Schedule_approval) • By: automatic . . . . Unlike “pure” ECA, the artifacts and macro life-cycles provide a solid structure for the workflows

  18. Associating Services to Artifacts 3:Goals+Constraints • Can we provide business stake-holders with something higher-level and broader than ECA rules • Illustrative examples (diff between goals/constraints is gray) • “absolute constraint”: A task cannot start until its predecessors have ended • “absolute goal”: each task in schedule must have optimality > 75 • “preferred goal”: obtain the highest overall optimality • The absolute constraints and goals might typically be captured using • Variations on first-order logic and/or temporal logics, or • OMG’s Semantic Business Vocabulary and Rules (SBVR) We are exploring • Various approaches to capture Goals+Constraints • How to map from Goals+Constraints to ECA, procedural

  19. IOPE Pictorial + conditions Traditional procedural IBM’s current offering Goals + Constraints ECA Triggers and flows Summary: Key options for artifact-centric WF models Data Modeling Ariifacts Macro Life-cycles Services Associations Process Modeling (structured around artifacts) More systematic implementation Workflow Implementation (flow mgmt, services, databases, resources, …)

  20. A rich parallel With database mgmt Relational Calculus SQL Optimized algebra query plan Query plan implementation A vision for a multi-tiered artifact-centric workflow framework Declarative Specification (Goals+Constraints – SBVR?) Business managers Business analysts IT architects Business analysts IT architects IT system engineers Declarative Specification (ECA) IT architects IT system engineers IT developers Conceptual Realization (Procedural, optimized) IT system engineers IT developers DBAs, … Physical Realization (DBs, queues, triggers, …)

  21. Outline • Artifact-centric workflow models • Research challenges and directions • Conclusions

  22. Data Modeling Artifacts IOPE Macro Life-cycles Pictorial + conditions Services Traditional procedural Associations Process Modeling (structured around artifacts) Goals + Constraints systematic implementation ECA Workflow Implementation (flow mgmt, services, databases, resources, …) Triggers and flows Research Questions: Detailing the models • Is ER the “best” data model? Compare ER vs. XML vs. . . . • Create preceise syntax/semantics for ECA and Goals+Constraints • What is “best” approach to concurrency in ECA? For Goals+Constraints? • What logics are most useful for IOPEs, ECA, Goals+Constraints? • How to capture precisely “preferred constraints”?

  23. Research Questions: Analysis Data Modeling Artifacts IOPE Analysis at and across kinds of associations • ECA: reachability, termination, deadlock, … • Goals + Constraints: same • Goals+Constraints  ECA: correctness • ECA  Procedural: correctness Preliminary work [Bhattacharya et al, BPM 2008] • In quite limited settings, reachability, etc, is NP-complete for CA rules Pictorial + conditions Macro Life-cycles Traditional procedural Services Associations Goals + Constraints Process Modeling (structured around artifacts) More systematic implementation ECA Workflow Implementation (flow mgmt, services, databases, resources, …) Triggers and flows

  24. Research Questions: Synthesis Data Modeling Artifacts IOPE • Given a set of Goals+constraints, • Can you automatically generate ECA rules that correspond to G? • Can you automatically generate a procedural spec that corresponds to G? • Preliminary work [Fritz+H.+Su, in prep.] • In limited setting, can perform synthesis in 2EXPTIME Pictorial + conditions Macro Life-cycles Traditional procedural Services Associations Goals + Constraints Process Modeling (structured around artifacts) More systematic implementation ECA Workflow Implementation (flow mgmt, services, databases, resources, …) Triggers and flows

  25. Data Modeling Ariifacts IOPE Macro Life-cycles Pictorial + conditions Services Traditional procedural Associations Process Modeling (structured around artifacts) Goals + Constraints More systematic implementation ECA Workflow Implementation (flow mgmt, services, databases, resources, …) Triggers and flows Research Questions: Understanding Generic / Specialization Use hierarchical aspect of state machines • What are design guidelines for different approaches? • What is precise relationship – can each simulate the other? • Incrementality: • When is incremental analysis more tractable than full analysis? • When is incremental synthesis more tractable than full synthesis? Use different services Use different associations

  26. Outline • Artifact-centric workflow models • Research challenges and directions • Conclusions

  27. Related Work (Selected) • Artifact-centric and Adaptive Business Objects • [Nigam+Caswell 03, Kumaran+Nandi 04, Bhattacharya et al 07] • Pioneering combo of artifact + life-cycle as basis for workflow • Document Engineering • [Glushgo+McGrath book] • Like artifacts, but focused on exchange between organizations • Vortex • [H. et al 99, H. et al 00] • Similar to artifacts, services have declarative “guards” • Evolving Documents in Active XML • [Abiteboul+Vianu 08] • Services associated with leaves of XML documents; analysis results • Semantic Web Services, OWL-S • [McIlraith+Son+Zeng 01, H.+Su 05] • Focus on automatic discovery, composition, invocation, monitoring of services • Workflow may be the “low-hanging fruit” for SWS techniques

  28. Relational Data Model Declarative (SQL) Queries Graph-based Data Model Navigational Queries Logical Logical Manual Automated Physical Physical Physical Storage (files, indexes, …) COBOL, IMS, … Artifact Classes Sequential Process Modeling Goals (Declarative) Tasks (Declarative) Ad hoc Data Mgmt Logical Logical Manual Physical Automated Physical Workflow System Workflow Implementation An analogy to Relational Databases (à la Jianwen Su) After Before Databases Workflow

  29. University/Institute Collaborations << partial list >> Active • UC Santa Barbara • University of Zurich • FORTH in Crete • UC San Diego Emerging • University of Rome – La Sapienza • University of Balzano • Penn State • INRIA There is lots of research to be done, and we are eager to collaborate with academia/institutes

  30. Summary • Artifact-centric provides a new basis for designing (and implementing) workflows that is • Easy for business stake holders to understand • Can enable flexibility in • Evolution • Component re-use • Generic / specialized • Has already shown its value in the field • Artifact-centric can support a spectrum from procedural to declarative workflow specification • A declarative approach could dramatically simplify workflow design, evolution, specialization, component re-use, . . . • This framework raises many research questions

  31. Backup slides • In artifact-centric workflow, is the challenge of synthesizing procedural workflows from high-level goals+constraints a “low-hanging fruit” for techniques from (and advances to) semantic web services?

  32. OWL-S (Formerly DAML-S) • An important framework to add semantics to web services: • An upper ontology for describing properties & capabilities of web services using OWL presents (what it does) • input types • output types • preconditions • effects Resource ServiceProfile provides Service describedby(how it works) supports(how to access) ServiceGrounding ServiceModel • process flow • composition hierarchy • process definitions • communication protocol (RPC, HTTP, …) • port number • marshalling/serialization

  33. Describe services using “IOPEs” • Input parameters • Output parameters • Pre-conditions • (Conditional) Effects OWL-S Atomic Process Acct# Debit_ Account Confirm# • To model impact on real world, this model builds on Situation Calculi (cf. also PSL) • Use of “Fluents” to model real world, for pre-conditions, effects • Use tree of situations to represent possible execution paths Amount Account_Balance If balance of ACC# is  Amount, then replace record using Balance – Amount and set Confirm# = new If balance of ACC# is < Amount, then no-op Owner Balance Acct# . . . Mary 1234 $500 . . . . . . . . . “Real World”, or “Fluents” “Conditional Effect”

  34. Messages between services – modeled as keyed relations • Impact on “real world” Representative Semantic Web Services model --Colombo: “Signatures” that combine semantics and messaging behaviors [Berardi, Calvanese, De Giacomo, H., Marcella VLDB ’05] Bank Client (human or machine) Store Ware- House “Real World” • “View” of internal process model – guarded automata

More Related