Erfahrungsbericht Wenn Rules Prozesse malen dominique.gueniat@swisscom.com 14. SI-SE Fachtagung Business Rules 24 25. Jan. 2008 Universität Zürich 18 Januar 2008, dominique.gueniat@swisscom.com
Agenda Background Idea & Vision Evolution of the Process Engine Summary 2
What is OMS Order Management Swisscom Full automation of business processes in the retail business of Swisscom. Processes cover administrative and technical aspects. Products Wired Line Access Broadband Services (xdsl) Bluewin TV DSL@Mobile VoIP 18 Januar 2008, dominique.gueniat@swisscom.com 3
OMS Architecture Overview 4
Agenda Background Idea & Vision Evolution of the Process Engine Summary 5
The normal way to develop processes 6
The Vision 7
The Human Process Fulfillment Algorithm Humans know Which steps Conditions for each step Dependencies between steps evaluate iteratively what to do react on changed conditions can obtain facts on demand There is no process which can t be fulfilled by humans 18 Januar 2008, dominique.gueniat@swisscom.com 8
Agenda Background Idea & Vision Evolution of the Process Engine Summary 9
Solution Concept I Provide process knowledge no need to define a process 10
Proof of Concept I 11
Rules for Example Process The rules define when to start which step 12
Problem 1: Loops Technical problem not a requirement 13
Problem 2: Dependencies Rules have to determine when to start a step 14
Conclusion: Concept I Failed Problems Hard to read business aspects Too many rules needed Just a complicated solution to implement a sequence Reason Solution Rules have two responsibilities Path Evaluation (select steps to perform) Execution Control (determine step to execute) Reduce rules to path evaluation Delegate execution control to a specific component 18 Januar 2008, dominique.gueniat@swisscom.com 15
Improved Algorithm / Concept II Rules determine the specific path for each order 16
Declarative Path Definition (Painting Tools) Requested Step Declared Step Predecessor Relation Must be performed Must not be performed Path Path declares Which Which steps steps to to perform When When each each step step is is allowed to to be be started started Path Path can can change with with every every iteration B can be started when A Requested && complete Declared && startable B inherits A s Predecessors 18 Januar 2008, dominique.gueniat@swisscom.com 17
Rules Output for Example Process Example Process All Possible Paths X > 10 No Message X 10 No Message X > 10 With Message X 10 With Message 18 Januar 2008, dominique.gueniat@swisscom.com 18
Proof of Concept II Rules document process requirements Rules are are simple to to write & understand Maximum flexibility 18 Januar 2008, dominique.gueniat@swisscom.com 19
Graphical Editor for Template Path Template rule is always fired Paints the template path Can be replaced by data model Edit using graphical editor The graphical editor is based on Eclipse GMF and has been realized as a master thesis in informatics in collaboration with the University of Fribourg See Graphical Aspect Model Editor 18 Januar 2008, dominique.gueniat@swisscom.com 20
Declarative Process Specification Mandatory Step Optional Step Predecessor Relation Must be performed for each process instance Must be performed in case the condition is true Condition will be tested by rule(s) B can be started when A Requested && complete Declared && startable B inherits A s Predecessors Specification documents requirements not not a solution No No translation of of requirements Very simple to to use use 18 Januar 2008, dominique.gueniat@swisscom.com 21
Declarative Specification of Example Imperative Declarative 22
Impact on Process Analysis Identify the the steps Ask Ask for for each step step? Must this this step step always be be performed Yes: Yes: Add Add mandatory step step No: No: Add Add optional step, define condition? Are Are there dependencies Yes: Yes: Add Add predecessor(s) Local analysis Less complex, less less error prone Changes are are simple Only Only one one language from from analysis until until implementation 18 Januar 2008, dominique.gueniat@swisscom.com 23
Vision and Reality We are closer to the vision than we expected 24
Agenda Background Idea & Vision Evolution of the Process Engine Summary 25
Pros and Cons + Think local, implement local, change local + Rules can can be be reused for for different processes + Linear complexity of of implementation to to the the requirements + One One language for for analysis, specification and and runtime + Almost as as flexible as as humans + Event handling + Error handling + Can Can obtain facts on on demand Not Not standards conform therefore obviously wrong 18 Januar 2008, dominique.gueniat@swisscom.com 26
All beginnings are difficult It s It s difficult to to define the the responsibility of of the the rules to to design the the facts to to realize that that it s it s difficult Design errors might lead lead to to the the wrong impression that that rules aren t suitable to to solve the the problem Which doesn t mean that that every problem can can be be solved by by rules Tip Tip Write rules first first Review rules critically (do (do you you like like them?) Ask Ask experts 18 Januar 2008, dominique.gueniat@swisscom.com 27
Conclusion Approved by Swisscom: >100 95% 25 000 500 000 Processes automated Clean Orders (Business Case >60%) Orders per workday Process steps per day 30 000 000 Orders processed It is very advantageous to evaluate processes by rules we would do it again 18 Januar 2008, dominique.gueniat@swisscom.com 28