Getting to the Handshake Leveraging Business Rule Technology through Architecture, Design, and Practice

1. Required Slide SESSION CODE: ARC301 Getting to the HandshakeLeveraging Business Rule Technology through Architecture, Design, and Practice Putting Business Rules To Work Loren Goodman Chief Technology Officer InRule Technology

2. Agenda • A bit of background on the whole thing • Define business logic and other related terms • Review today’s typical business logic lifecycle • Jointly work through the Thinking In Rules approach • Design • Driving out Business Logic Services • Getting to the “Handshake?” • Artifacts capturing the design • Implementation • Decision services and the Business rule object model (BROM) • Integration with calling application • Lifecycle • Pros and Cons of alternatives for authoring and playback • Review

3. Why do we need this Session? • Business Logic is Boring!(to us, that is) • Business Logic Changesfrequently • Changes are Expensive, Slowand Prone to Error • Requires changes to source code • Deploying binaries and limitations of release cycles • The Business and IT are not working as a team • We want to reduce the costs, time frames, frustration, andrisksassociated with these changes • We want to make • Business Logic Definitiona Businessproblem • Business Logic Executiona Technologyproblem

4. Site Text • The Story • The Remedy • The Realizations • We were using, but not leveraging IT capabilities • What was important to who is out of whack • The value of having a single point of definition • The Result • Costs Went Down • Quality Went Up • Customer Satisfaction Went Up • What we are talking about today is using the same pattern for business logic

5. Define Key Terms • Authoring / Encoding • Process of unambiguously declaring logic and system behavior • Authoring is done in the authoring tool • Encoding is done in the development environment • Vocabulary • Body of mutually understood phrases • Used to communicate intent • Verification / Playback • Proving that the authored behavior is the intended behavior • Verification is done first person in the moment • Playback is presented

6. Points to Make • Its all about Communication • Its all about Accountabilityand Ownership • Its all about PlaybackandReducingTranslation • Actually… its really all about Fishing • Define communication first - communicate content second • The process around it drives out the value of this technology • At the end of the day, it is not really that different • The people closest to the business still define the behavior • The difference is that now they do it more efficiently and with full accountability and ownership • The actual handshake is important!

7. The Handshake • Mutual commitment to the importance of Communication • Both Literaland Symbolic • Point of Agreement from which downstream disputes can be resolved • Signifies the Acceptance of Accountability on both sides • Demonstrates appreciation of unique skills and contributions • Gets our eyes on the prize

8. What is Business Logic • What is Business Logic • Underlying system of reasoning that drives business behavior • In constant flux • What is it made of • Rules • Reference Data • People and Perceptions • What is it really doing? • Making Decisions • Reactingto a Situation

9. What is Business Logic Agility? • In a nutshell: • How gracefully can we change the important stuff over time? • Combination of: • Ability to takeaction and having the knowhow to do so • The freedom of trial&error mixed with singular decisiveness • Alignment of accountability, control and ownership • Defining, Testing, and Interrogating issues Quickly • Greater Agility Correlates to: • Happier Campers • Lower Costs and Shorter Time Frames • Increased Accuracy, Transparency and Visibility

10. Who are the Players?

11. Business Logic Life Cycle Today • Starts with a Need • Accomplished via the Means • Ends with the Behavior

12. Typical Life Cycle Phase 1 - Requirements

13. Typical Life Cycle Phase 2 - Development

14. Typical Life Cycle Full

15. Work Item Based Life Cycle • Usually more efficient than traditional waterfall • Eliminates a Translation Layer • Efficiency improves over time • Developer must be proactive • SME must learn TFS / Other Tool • Evolves over time • Good place to discover vocabulary!

16. Life Cycle Goal • Full Control • Full Accountability • Full Ownership • Leveraging Technology • Separated Concerns

17. Background Business Case • Example Business Case • We are an electronics store with 50 retail stores and a web based marketplace • Noticed a lot of television returns during the second week of February • The Problem • We are getting way too many returns of large televisions right after the Super Bowl • The Need • We need to enforce a 15 percent restocking fee on televisions which were purchased just to watch the Super Bowl

18. So, How Do We Get There? • Need Clear OwnershipBoundaries • How do we outsource development? • Reduce the Number of Translations • How do we improve communication and remove ambiguity • Capture Intent as Close to the Source as possible • Transparent execution based on definitions • Strong playbackmodel that authors can believein • Separate Logic Definition from Logic Consumption

19. The Thinking In Rules Process • 1 – Variability Analysis • 2 – Questions and Answers • 3 – Information and Actions Analysis • 4 – Vocabulary Negotiations • 5 – Design Business Rule Schema • 6 – Design Decision Service Contract • 7 – Hook up existing Code to use Decision Service • 8 – Edit Rules – Deploy - Repeat

20. Step 1 - Variability Analysis • Figure out • What Changes • How Frequently • Who owns it • These are Variability Points • Estimate costs and risks for each variability point • Per change = Resource time + Impact of turn around time + Deployment costs • Annual Cost = Estimated # of changes per year * Cost per Change • Go for the low hanging fruit • Capture in Agility Requirements Document

21. What we know so far

22. Question and Answers

23. Step 2 - Question and Answers • Go through each Variability Point • Must pass the Turing Test • Figure out how to phrase it as a question • Developer Asks • SME Answers • For the SME • The Question is the Authoring Context • The Answers are Directives for Action • For the developer • Asking the Question is the Invocation Point • The Answer comes from the Decision Service

24. Information and Actions Analysis ??? ???

25. Step 3 - Information and Actions Analysis • For each Authoring Context • What information is needed? • What actions are needed? • Detailed Walkthrough of • Rules, artifacts, existing code, folklore • Identify all • Pieces of Consideration • Directives for Action • Ultimately captured in Authoring Requirements Document

26. Information and Actions Example Purchase Date Superbowl Date Items in order Item is big screen tv • Notify Customer • Message • Receipt Text • Initials Required

27. Initial Vocabulary Purchase Date Superbowl Date Items in order Item is big screen tv • Notify Customer • Message • Receipt Text • Initials Required

28. Finalize Vocabulary Negotiations • Best Part! • Get the SME, the Developer, and/or the analyst in the room • Go through each authoring context • Work through each piece of vocabulary • Talk about what each phrase means • Get both sides agree to each pieces meaning • Get the Handshake!! • Concerns Separated!

29. Where Are We At Now • We Know • What Changes (Variability) • What our Decision Services are (Q&A) • How Logic is Described (Info and Actions) • Vocabulary Requirements (Handshake) • Now we need to put it together and make it work • Design the BROM (Business Rules Object Model) • Design the Decision Service • Hook up the Decision Service • Populate the BROM • Call the service • Carry out the actions returned • Edit the Rules • Test the Rules

30. Mapping The BROM

31. BROM Object Model • Vocabulary To Schema • Information • Actions

32. Point of Sale Decision Service

33. Calling the Decision Service • Passes the Turing Test • Minimal testing surface

34. Logic Execution Options • Rules In Code • Rules In Rule Engine • Developer Authored • Analyst Authored • SME Authored

35. Rules in Code Implementation • SME/Analyst creates document containing the rules • Organized around authoring contexts • Only uses accepted vocabulary • Vocabulary contract enforced by hand • Eliminates ambiguity and iterations • Any language outside the vocabulary goes back to the SME for clarification • Execution done in service code • Playback done through testing • Still requires deployment of binaries

36. Rules in Rule Engine Implementation • Developer Authored • SME/Analyst creates document / work item containing the rules • Playback still required and done through reporting • SME/Analyst Authored • Developer sets up the initial vocabulary • Rules are created, verified and published directly in tool • All Cases • Vocabulary contract enforced by tool • No translation - Execution occurs against authored rules • Deployed as data

37. Rule Engine Implementation • Vocabulary Defined in Authoring Tool • Rule Authored using Vocabulary

38. Rule Engine Implementation • Playback accomplished via Reporting

39. SME vs. Analyst Authoring

40. The Big Picture

41. Thinking In Rules • Walked through the problems with the current life cycle • Talked about the importance of • Accountability • Transparency • Playback • Talked about level of implementation • Developer Authored • Analyst Authored • SME Authored • Covered the vocabulary design process • Q&A, Info and Actions, Vocabulary • Decision service implementation • Populating Inputs, Calling Service, Carrying out Directives • Roles and Responsibilities for On Going Life Cycle

42. Questions and Comments

43. Required Slide Track PMs will supply the content for this slide, which will be inserted during the final scrub. Track Resources • InRule Technology www.inrule.com

44. Required Slide Resources Learning • Sessions On-Demand & Community • Microsoft Certification & Training Resources www.microsoft.com/teched www.microsoft.com/learning • Resources for IT Professionals • Resources for Developers • http://microsoft.com/technet • http://microsoft.com/msdn

45. Required Slide Complete an evaluation on CommNet and enter to win!

46. Sign up for Tech·Ed 2011 and save $500 starting June 8 – June 31st http://northamerica.msteched.com/registration You can also register at the North America 2011 kiosk located at registrationJoin us in Atlanta next year

47. © 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

48. Required Slide