Lessons Learned from Development of Large-Scale Rules-Based System

Transcription

1 Lessons Learned from Development of Large-Scale Rules-Based System Business Rules Forum Presented by: Lynne Harbin Philip Matkovsky October 2007 Orlando, FL 1

2 Abstract This presentation focuses on a real-world implementation of business rules management system within a large-scale re-engineering/re-host effort within a civilian Federal agency. We will discuss the definition of the business process well suited to support with systems using rules engine and focus on decisioning elements embedded within the process, volatility of processes (e.g. changes to rules through policy changes), and interdependence and complexity of rules. Our presentation will additionally identify where improvement can be gained, namely analysis and modeling challenges that require a modified framework for process analysis/modeling, use case definition, rule simulation and rule validation. Presentation will include case-study and quantitative examples. 2

3 Overview Initiative description Define life-cycle of development initiative Discuss business rules management in context of initiative and in context of lifecycle Discuss how business rules management implemented throughout life-cycle Discuss opportunities for improvement within context of life-cycle 3

4 Initiative Description: Summary Re-host aging enrollment system for Veterans Health Administration Implement platform that allows streamlining of business processes and introduces systems development and maintenance efficiencies 4

5 Initiative Description: Business Perspective The Veterans Health Administration operates the largest healthcare delivery system in the U.S., serving over 7.5 million enrolled participants, with roughly 5 million receiving health services through the system Governed Largely by Title 38 United States Code and 38 Code of Federal Regulations Chapter 17 Within limits, interpretations can be applied to policy by the Administration, e.g. Threshold values for means testing Updates to dates Combat locations Enrollment group thresholds, etc. 5

6 Initiative Description: Business Perspective Eligibility Determination Eligibility factors are determined and verified Also covers means testing and income verification; if need is determined, veteran does not incur charges for service Decision regarding eligibility Eligible Veterans are Assigned to Priority Groups Enrollment is managed through a priority system: There are currently eight priority groups; Priority 7 and 8 have subgroups Highest priority enrollment is for veterans with service-connected conditions rated % disabling, lowest priority for higher income non service-connected veterans Secretary sets enrollment group threshold by priority group Enrollment decision is applied after determining priority group assignment Over 7.5 Million Enrollees Roughly 900K new enrollees per year. Veterans enrollment priority and status may be adjusted due to changes in compensation or pension award, financial or health status, or military service factors. 6

7 Initiative Description: Systems Perspective Centralized System Expert system performs complex business determinations Data updates Business determinations Message-based interaction with distributed systems HL7 events Adopt Service Oriented Architecture (SOA) pattern 7

8 Initiative Description: Systems Perspective Geographically Distributed Systems Local Sys Local Sys SSA Inter-dept. Sharing VBA Inter-admin Sharing Internal VHA Interfaces External Interfaces Messaging subsystem Eligibility/enrollment determination Message and data processing Rules subsystem Internal Java Services Presentation subsystem Enrollment System IV and EE staff VAMC staff 8

9 Business Rules Management: Overall Fit with Initiative Driver Current environment proves cumbersome to make major changes to business rules Legacy rules maintained in source computer code, inconsistently documented requirements/design documents Gain Mechanism for rapid deployment of changes to policy and/or business in systems without excessive costs: time, resources Conversion of rules from current mode provides opportunity to review, rationalize and manage rules in business-friendly manner 9

10 Business Rules Management: Overall Fit with Initiative Driver Business domain is rulesintensive process with close integration between policy and operational processes Major modernization effort provides opportunity to implement accessible rules sets for service in multiple modes Gain Rules management enables business to closely maintain rules as business assets; business identified staff to manage rules Enable organization to use standardize business rules for centralized, distributed, and self-service; serves as foundation for subsequent process and systems enhancements 10

11 Life-Cycle of Initiative Modified Rational Unified Process Project planning defined five major iterations Including: /Analysis Testing (QA and customer) Single ultimate production release Note: Fits within service-oriented architecture (SOA) 11

12 Life-Cycle of Initiative : Business case Business modeling Requirements : Analysis and design Initial implementation : Implementation Testing Initial deployment : Implementation Testing and validation Deployment 12

13 Business Rules in the Life-Cycle Business case Business case was supportive of business rules Business modeling Business process models and use case models developed using UML framework Requirements Requirements documented in RequisitePro 13

14 Business Rules in the Life-Cycle Activity Business Case Business Modeling Requirements Approach Taken Assess suitability rules management with IT system; Multi-dimensional assessment of rules systems fitting system Develop business models in UML (activity diagram) Generate requirements in RequisitePro; Document rules in MS Word and decision-tables Lesson-Learned Make use of explicit business analysis dimensions when assessing rules management; Include business analyst in assessment of rules management Identify Business Rule stereotype; Integrate Business Rule stereo-typed activity with analysis rules repository; Generate business information model Include rule artifacts within use case 14

15 Business Rules in the Life-Cycle Enrollment System Receive enrollment event (HL7) <<Business Rules>> Apply message handling rules <<Service API>> Retrieve person Is message rejected? Is person found? <<Business Rules>> Apply data rules eligibility data updated <<Business Rules>> Determine enrollment priority group <<Exception>> Generate Enrollment event Exception <<Exception>> Generate person not found exception Business rules stereotyped activities contain authoritative depiction of defined business rules. Representation within UML business flow preserves context in which rules are invoked. priority group set <<Business Rules>> Determine primarysecondary eligibilities <<Business Rules>> Set enrollment status 15

16 Business Rules in the Life-Cycle VA Eligibility Ce nte r Reference eligibility factors <<Business Rules>> Determine enrollment priority group Is SC disability >= 50%? Is SC>0%, & >$0, & Unemployable = yes, & not AA, HB or Pension? Is SC disability = to or between 30 and 49%? Is SC disability = to or between 10 and 29%? group =1 group =2 group =3 Is POW, PH, Military Disability? Receiving AA or HB? group =4 Is catastrophically disabled? Stereotyped activity can contain detailed rule flow (e.g. rule tree). group =5 Receiving VA pension or Medicaid eligibile? group =6 WWI, MBW, 0% SC compensable? Is exposed to AO in Vietnam, IR, EC? Combat veteran eligibility end date expired? [ no, veteran declines MT ] Agrees to pay? Has veteran completed MT? PG not assigned Compare income to MTT Compare income to GMTT Is income greater than Is net worth > NET MTT? WORTH THRESHOLD? group =5 Is Enrollment Group Threshold Set to Stop New Enrollments group=7a Is noncompensable 0% SC Is income > MTT & < GMTT group =8A Continuously enrolled since Continuously enrolled as of xx/xx/xx (set date)? group = 8E Note: For future use - if Enrollment threshold group is changed from PG 8 to PG 7. Is income > MTT & < GMTT group = 7C Continuously enrolled group = 8C s ince group = 8G Is noncompensable 0% SC group = 7E group = 7G 16

17 Business Rules in the Life-Cycle <<Business Rules>> Ruleflow 202: Determine enrollment priority group Stereotyped activity could point to other business rules environment with a direct reference to the ruleflow, e.g. decision tables, rule repository. Business rules analysis repository 17

18 Business Rules in the Life-Cycle Analysis and design Requirements embellishment Design model Initial implementation Architectural verification implementation 18

19 Business Rules in the Life-Cycle Activity Analysis and Design Approach Taken Developed analysis model (as conclusion of analysis phase); Generate design model; Utilized UML artifacts (e.g. class modeling, sequence diagramming, etc.); Rules developed as part of construction phase (versus analysis) Lesson-Learned Still experienced volatility in rules definition; Include rule development within analysis and design phase; Include rule validation phase (this activity could be performed with business analyst and/or with systems analyst) Initial Implementation Generated architectural release to verify interaction between architecturally significant components Assess alternative architectural patterns; Multiple deployment frameworks exist for rules engines assess alternative patterns 19

20 Business Rules in the Life-Cycle Alternative A Messaging subsystem Rules subsystem Internal Java Services Presentation subsystem Server 1 Messaging subsystem Rules subsystem Internal Java Services Presentation subsystem Server 2 Messaging subsystem Rules subsystem Internal Java Services Presentation subsystem Server 3 If proven viable, Alternative B may result in considerable licensing cost avoidances Alternative B Messaging subsystem Internal Java Services Presentation subsystem Server 1 Messaging subsystem Internal Java Services Presentation subsystem Server 2 Server 3 Rules API Rules subsystem 20

21 Business Rules in the Life-Cycle Implementation Allocated use cases to iterations Performed iterative construction of system Testing Conducted black-box, scenario-driven testing Initial deployment Rolling system portions of system (e.g. legacy systems changes) 21

22 Business Rules in the Life-Cycle Activity Implementation Approach Taken Developed iterative construction of allocated use cases; Rules development assigned as construction task Lesson-Learned Develop overall rule framework Testing Performed scenario-driven tests (e.g. provide input and expect a defined output) Include rule outputs to verify what types of rules invoked as part of specific scenarios; Generate rule output for triage/review by analysts 22

23 Business Rules in the Life-Cycle Testing and validation Conducted performance profiling Empirical performance testing Deployment Parallel deployment strategy Comparison of legacy system outputs with reengineered system outputs 23

24 Business Rules in the Life-Cycle Activity Testing Approach Taken Software profiling and Empirical performance testing Lesson-Learned Profile performance within rule service Deployment Parallel deployment strategy To be determined 24

25 Business Rules in the Life-Cycle Duration in Event Processing 13 4 Level of transparency of processes once in rules processing can be improved 0 Factor Total Message Enrollment Determinations Business Rules Detail > 250,000/ Day Enhanced tools for monitoring, tuning rules processing are required Messages >1,000,000/Day Number of Determinations 313 /Minute 25

26 Conclusion Initiatives: Business Rules management systems fit within re-hosting/re-engineering efforts Assessing Rules Management Systems: More emphasis needs to be placed on integrating rule management with the business Business Modeling: Need a mechanism to integrate business process definition with rules definition Requirements: Incorporate more robust rules artifacts with use case definition Analysis and Design: Include a rule validation activity (systems or business analysts validate detailed rules flows) 26

27 Conclusion (cont d) Architectural Alternatives: Identify architectural alternatives for implementing rules services implications for licensing Implementation: Beware of very expensive class library built in a Business Rules Engine; ensure that architectural iteration evaluates at least two patterns for rule service Testing (functional): Include rule output within testing process Testing (performance): Develop mechanisms to profile performance within rule sets 27