1. © 2014 IBM Corporation The BE 2 model: When Business Events meet Business Entities Fabiana Fournier and Lior Limonad 8 September 2014

2. © 2014 IBM Corporation Motivation 2 BPM enginesCEP engines Both engine types employ a specification language to allow designers define their desired behaviors BPM engines usually employ a specification grammar that can represent ordinary business operations CEP engines typically employ a specification grammar that can represent irregularities and unique situations that require careful attention

3. © 2014 IBM Corporation Motivation 3 BEMTEM The BE 2 model BEM and TEM: -Declarative -Computation independent -Formal semantics to enable automatic transformation into executable code -Both intended for non-IT experts

4. © 2014 IBM Corporation The Business Entity Model (BEM) 4 –Modeling approach introduced by IBM in 2003 (Nigam & Caswell) –Specification comprises: –Information - holds all biz- relevant data about this entity over full lifetime –Lifecycle - specifies all possible evolutions of a BA instance –A BE often cuts across organizational silos, providing an end-to-end view of operations ‘Customer Order’ in GSM Examples: Chequing Account, Financial Deal, Insurance Claim  An fundamental construct: Business Entity (a.k.a Business Artifact) A key conceptual dynamic entity (or object) that arises in, and flows through a portion of, the operations of a business.

5. © 2014 IBM Corporation Guards, Stages, Milestones (GSM)  A declarative approach to specifying the lifecycles of business entities  Adopted as the standard model in the OMG’s CMMN 1.0 standard (January 2013)  The specification comprises an hierarchy (‘tree’) of stages, each designating possible changes between a set of pre-conditions (‘guards’) and a set of goals (‘milestones’) –Stage – composite stages enable hierarchical clustering of work, atomic stages are the tasks where the actual work is performed –Progression is controlled by ECA-like rules (named “sentries”) of two types: Guard – an entry criteria that govern whether the stage can be launched Milestone – a business-relevant operational objective marking the completion of a stage 5 Collect & Assess Info Stage Guard: Entry Criterion Milestone: Termination Criterion “on the end of Check Customer Policy task if the policy is in effect and applicable to this claim”.

6. © 2014 IBM Corporation The Event Model (TEM) TEM Building Blocks 6 TEM Concepts TEM Glossary TEM Diagrams TEM Principles TEM Logic Specification

7. © 2014 IBM Corporation The Event Model (TEM) TEM Logic Specification 7 The Event Derivation Table (EDT) The Event Computation Table (ECT)

8. © 2014 IBM Corporation The Event Model (TEM) TEM Logic Specification 8 The Event Derivation Table (EDT) For each derived event there is a single EDT Conditions are assertions on Events and Facts The relationships among conditions is “AND” A condition can assert that an event did not happen (is absent) Context part Temporal: When? Segmentation: Partition by

9. © 2014 IBM Corporation The Event Model (TEM) TEM Logic Specification 9 The Event Computation Table (ECT) How we compute fact types of derived events

10. © 2014 IBM Corporation10 Illustrative Example – The Import and Export Scenario

11. © 2014 IBM Corporation11 Illustrative Example – The Import and Export Scenario The Business Entity Model (BEM)

12. © 2014 IBM Corporation12 Illustrative Example – The Import and Export Scenario The Event Model (TEM )

13. © 2014 IBM Corporation Our Integration Approach  An ontology based approach –Ontological Expressiveness – the capacity of a modeling grammar to describe all ontological concepts completely and clearly –Ontological reference by Mario Bunge (1977, 1979) – originally developed to depict the real world of which our domain of analysis is part of (i.e., the business domain)  Step 1: provided each model construct with its ontological interpretation  Step 2: scanned for semantic equivalences, potentially leading to one of the following deficiencies: –Construct overload – a modeling construct has more than one ontological interpretation –Construct redundancy - two (or more) modeling constructs share the same ontological meaning –Construct excess – a modeling construct which has no ontological meaning 13 OntologyModel Overload! Redundancy! Excess!

14. © 2014 IBM Corporation Our Integration Approach  Using the ontological interpretations as a baseline, several semantic equivalences among the two grammars were identified  The closest equivalence was concluded between the notion of a “(sub)stage” in BEM, and the notion of a “situation event type” in TEM  To eliminate construct overload in the unified grammar, we decided to augment BEM with a new type of a (sub)stage, to distinguish its interpretation from all other stages in BEM which do not correspond to situation events modeled in TEM 14

15. © 2014 IBM Corporation Adding Situation Stages - Principles A Situation Stage is a specific type of stage in GSM which corresponds to a single Situation event type in TEM  For each Situation Stage modeled in BEM: –All triggering events in the guards of that stage should match the relevant raw events which can trigger the derivation of the corresponding situation event type in TEM. –The situation stage should include a milestone whose triggering event type should match the situation event type in TEM.  For each Situation Event Type modeled in TEM: –The Partition by field in the TEM Derivation table should be modeled as the BE type which consists of the corresponding situation stage in its lifecycle model. –The Temporal context in the TEM Derivation table is determined by the guarding events in the corresponding BEM situation stage. Specifically, the event component in each ECA rule of a guard sentry should be modeled a corresponding "When context" expression in TEM. 15

16. © 2014 IBM Corporation Adding Situation Stages – High level Modeling Steps 16 "Sunny day scenario": capture key business commitments as BEs while staying ignorant of any situation exception handling. Modeling of exceptional situations with TEM For each business event which calls for exception handling or for any additional event-driven situations that requires an action, model a corresponding TEM.

17. © 2014 IBM Corporation Adding Situation Stages – High level Modeling Steps 17 Modeling the integration For each situation in TEM add a corresponding situation stage in BEM, such that: The stage's level coincides with the temporal context in TEM The BE instance corresponds to the segmentation context in TEM If there is no such BE type modelled in BEM, then create one or seek for one with identical business meaning. Add a new Stage which will handle the action to be carried out as a result of the situation detected. Shipment Delay Derivation

18. © 2014 IBM Corporation18 Illustrative Example – The Import and Export Scenario Augmenting the BEM Lifecycle Model with Situation Stages

19. © 2014 IBM Corporation19 Illustrative Example – The Import and Export Scenario Augmenting the BEM Lifecycle Model with Situation Stages Situation stage New stage

20. © 2014 IBM Corporation Conclusions Future work  The BE2 model provides a semantic bridge, and enables the business user to have a “better picture” of all its operations, while maintaining a separation of concerns and avoiding redundancy or omission of important steps in the process  BEM: means to express the pivotal view of the business  TEM: provides a deeper dive into the intrinsic complexity associated with some event-driven operations  Future work includes empirical validation of the model 20