The April 20, 2006 meeting of the Business Rules User Group (BRUG) was very well attended with 22 people participating live in St. Paul and another 20+ via web cast, courtesy of ILOG.  The second web cast BRUG meeting confirmed the popularity of this format with people participating from multiple states. 

Three presentations formed the core of the meeting:

• Business Rules Implementation—Pitfalls and Lessons Learned by Senior Artemis Alliance, Inc. Staff
• Moving Existing Business Rules into JRules by Paul Durfee, Senior Application Developer at Country Insurance & Financial Services
• Methodology, Tools and Techniques to Support a Collaborative Implementation of a Loan Origination System by Meg Lattery, Project Manager for the Single Family Mortgage Online System project for the Minnesota Housing Finance Agency. 

 Slides from all three presentations are available on the Artemis Alliance, Inc. web site. www.ArtemisAlliance.com/brug.  Summaries of each presentation can be found elsewhere in this newsletter. 

Following a welcome and brief introduction of the meeting agenda by Wyatt Wood, the three presentations were given.  

In closing, Wyatt reminded attendees that we are also looking for content and speakers for the BRUG newsletter and meetings.  Contact Wyatt at wwood@artemisalliance.com if you are interested.  Many of the on-site attendees stayed after the meeting ended to continue the sharing of information and experiences.  

Business Rules Implementation—Pitfalls and Lessons Learned
by Senior Artemis Alliance, Inc. Staff

Senior Artemis Alliance staff, drawing on their practical experience with what can go wrong from management, technical, and business analysis perspectives, provided insight into how and why business rules initiatives fail and strategies to assure the success of such initiatives.
 

The Management Perspective
(Pitfalls and  Success Strategies from the Management Viewpoint)
by Michael Krouze, Artemis CTO

Significant management pitfalls include:

• Management sees the initiative as ‘only’ a technical investment or enabler, and fails to take into account ALL of the costs involved.
• Management views business rules as a tactical, single application investment, and does not see the ‘big picture’, strategic benefits.
• Management hasn’t bought into the value of business rules, and fails to provide consistent support.
• Management does not understand the scope of the initiative and short changes the investment.

Success Strategies
Regarding determining the costs:

• Clearly analyze all rule costs and communicate to management.
• Make sure to include the following types of costs:
  -  Purchases
  -  Culture/process change
  -  Education
  -  Implementation
  -  Testing
  -  Maintenance

Regarding the strategic benefits:

• Examine all the benefits of business rules.
• Think of business rules as a strategic tool.
  -  IT agility
  -  Management of knowledge as an asset
• Leverage the investment in tools and skills.

Regarding management support:

• Educate, review competition, review success statistics to build confidence.
• Communicate strong support.
• Don’t vacillate – make a decision and stand behind it.

Regarding not short changing the investment:

• Understand the costs.
• Recognize needs for education and/or consulting support.
• Allow for proof-of-concept work and learning curve.
• Contract for support services from vendor.

Based on Michael’s experience, shortchanging the investment and viewing a business rules initiative only as a short-term, tactical investment are the two biggest barriers to a successful project. Management must understand that a business rules initiative is strategic in nature and represents a new way to manage its business.

The Technical Perspective
(Pitfalls and Success Strategies from the Technical Viewpoint)
by Krzysztof Karski, Artemis Senior Consultant

Significant technical pitfalls include failing to:

• Architect the concept model at the beginning of the project.
• Manage change.
• Establish an overall design vision for the rules engine and repository at the beginning.
• Establish appropriate testing methodology.
• Understand the capabilities and limitations of the rules engine.
• Understand that rules are not ‘just’ code or a new way to write if…then statements.

Success Strategies
For the concept model:

• Reduce change by having a well thought out and architected concept model.
• Have enough of a concept model architected so that future changes are additive, not structural.

For managing change:

• Establish a communication process between teams that might affect the concept model.
• Ensure the external entity model and the concept model evolve in the same direction.
• Agree early on data types, data constraints etc.
• Preferred approach: Iterative.
  -  Iterate quickly and often.
  -  Communicate frequently
  -  Integrate differences quickly and often
• Alternate strategy: Delay concept and entity model integration.
  -  Isolate concept model from external entity model churn.
  -  Figure out rules and concept model first, then figure out how to integrate with the external entity model.
  -  Get the concept model correct first and then figure out how to integrate it with external models.

For establishing an overall design for the rules engine:

• Choose an organizational paradigm and follow through.
• Establish rule organization, naming and categorization standards.
• Establish a vision for evolving the repository.
• Architect for rule portability and compatibility across the repository by having a well thought out and architected concept model.

For testing:

• Test early and often.
• Do not skip rule authoring steps including testing inside the rule authoring tool.
• Test in your environment first, not in application.
• Conduct quick, targeted testing.
  -  At minimum, set up quick and targeted smoke tests for your rules.
  -  Establish a reusable base of testing plumbing and base test data.
  -   Catch 80% of mistakes in the tool.
  -  Let the application testing strategy catch the remaining 20%.

For best use of the rules engine:

• Understand configuration options and their differences.
• Use wizards and auto generation techniques where possible.
• Use full tool set.
• Use the appropriate data types, built-in functions, etc.
• Understand your vendor’s work flow:
  -  Take full advantage of productivity aids by following the vendor’s rule authoring workflow.
  -   Understand the order of events when writing rules to avoid rework or unnecessary manual work.
  -  Use the rules engine for rules.
  -  Rule engines are not integration, data transformation or translation platforms.
  -  You should not have to write a ton of rules just to access, understand and return data.

For understanding why rules are not ‘just’ code:

• Use intermediary concepts.
  -  Define intermediary concepts globally and reuse them.
  -  Define simplification concepts that are used in everyday conversation and use them in the rules.
  -  Revisit OO analysis fundamentals and apply them.
  -  Write rules that sound like English.
• Follow rule writing best practices.
  -  Have each rule deal with one issue.
  -  Break up large decision logic blocks into many rules.
  -  Don’t write techie rules.
  -  Remember that rules are just not a different way to express if….then expressions.
   

The Business Analyst Perspective
(Pitfalls and Success Strategies from the Business Analysis Viewpoint)
by Alyce Neperud, Artemis Principal and Senior Business Analyst

Significant analysis pitfalls include:

• Resistance to change
• Separation of rules from requirements
• Poor repository planning
• Selecting the wrong people to be rules analysts
• Solving the same problem in different ways
• No champion

Success Strategies
To overcome resistance to change:

• Educate to provide better understanding of why the organization is doing it this way.
• Build support within all areas.
  -  Development
  -  Analysis
  -  Testing
  -  Project Management
• Enable them to “skin their knees”.
  -  Let the team make mistakes quickly and see the value of the approach.
• Bring understanding of the “big picture” and the value of the approach down-stream in the development process.

To prevent the separation of rules from requirements:

• Teach them to write good requirements and good rules.
  -  Avoid having one group writing requirements and another writing rules.
• Use concrete examples.
  -  Show the new version of artifacts after introducing the concrete examples.
  -  Tell the entire story in an integrated manner.
• Use short, fast iterations with experienced review to provide experience and feedback

To encourage good repository planning:

• Do not take a document centric approach--focus on writing good rules rather than on where they fit in the document.
• Use knowledgeable people in designing the rules repository.
• Work through the versioning and change management in detail.
• Execute full rule lifecycle testing of the repository.

To select the right rules analysts:

• Do not assume that every subject matter expert will be a good analyst.
• Do not assign critical tasks to people who are unproven.
• Have internal or external mentors who have time to help
• Pair experienced people with inexperienced.
• Explicitly determine skill levels of team members.

To avoid different solutions to the same problem:

• Establish model for sharing information and lessons learned.
• Consistency is essential to precision.
• Do not let separate groups make their own decisions.
• Have some experts looking across the entire set.
• Do not overwork your experts.
• Be careful in how you tasks are assigned to avoid overlapping work.

Alyce’s advice for the ‘no champion’ problem ia simple: Get one! No champion equates to a greatly reduced probability of success.

Moving Existing Business Rules into JRules
by Paul Durfee, Senior Application Developer at Country Insurance & Financial Services

Paul Durfee spoke, via the webcast, on his experience with Moving Existing Business Rules into JRules.  Paul has been developing business rules systems since 1993 for three insurance agencies and a government agency.  He is experienced in the use of Aion, Blaze and JRules. 

Paul provided a case study of an actual project that resulted when Country decided to go to a new JRules architecture.  The challenge was to move the existing business rule to the new architecture without impacting the mainframe.  Paul began with a statement of the following project goals:

• Share common rules among various processes instead of duplicating rules in separate sets of code.
• Place business rules in a supported tool running on a supported platform.
• Improve Business Rule run-time performance.
• Be able to better use business rules technology in other areas.

He then provided details of the old and new architecture. The JRules architecture has the following characteristics:

• All data is stored on Mainframe in VSAM files
• All data is read by COBOL and passed to JRules via WBI with one call
• WBI is deployed as a web service
• COBOL uses HTTP SOAP to call WBI
• JRules is deployed as a web service
• JRules is deployed under WebSphere on a box running Windows 2003 Server
• JRules is deployed as a EJB
• Each component could be replaced with minimal impact to the other components

The project was successful as evidenced by the following metrics:

• Common rules are now updated one time and in one place
• JRules and all other architecture components have vendor support
• Rules are accessible as web services from any system
• Run time performance has improved
  -  Rating Rules now run in 0.25 seconds vs. 1.2 seconds before
  -  Eligibility Rules Transaction is now less than 2 seconds vs. 8.5 seconds before

Paul concluded with the following Lessons Learned /Best Practices:

• Use the BAL
  - Good use of BAL allows for the Business to review rules without needing a separate document that must be maintained
  - Review the BAL regularly when being developed
• Object Model Design is crucial
• Use ILOG’s Professional Services to at least get a head start
• When in the Builder IDE, use the Function Set sparingly for code
• Build a good testing facility to enable faster and more reliable rules testing as business rules are complex and testing can be difficult and time consuming

Methodology, Tools and Techniques to Support a Collaborative Implementation of a Loan Origination System
by Meg Lattery, Project Manager for Minnesota Housing Finance Agency. 

Meg Lattery concluded the presentations with a very detailed and complete case study of a business rules initiative for the Minnesota Housing Finance Agency on Methodology, Tools and Techniques to Support a Collaborative Implementation of a Loan Origination System. Meg was hired as a project manager to lead the Single Family Mortgage Online System project for this State of Minnesota agency. In addition to the challenges involved in any major business rules initiative, Meg had to contend with state RFP and contracting rules.

The overall project goal was to “Transform the way the MN Homes Division does business with their Mortgage Lending Partners, Administrators of their loan products, the designated MHFA Trustee and MHFA’s Servicing Partner(s).” The project included both business and IT goals.

Business goals were to:

• Reduce turn around time to respond to business changes
• Ensure adherence to regulation and compliance mandates
• Increase transparency, auditability & traceability
• Empower business users
• Reduce costs and risks by improving efficiency

·         Ensure a Collaborative Environment for Mortgage Lending Partners and Administrators that provides the following benefits:
-  No more faxing
-  No more typewriters - forms available online
-  Business program manuals redesigned for ease of use
-  Program forms and documents reduced
-  Shortened approval timeframes

IT goals were:

• A web based system for Mortgage Lending Partners to access to their pipeline, funds availability and management of their organizational information
• Business Rules System (powered by the ILOG Rule Engine) that supported:
  -  Rule versioning and historical compliance reporting
  -  Integration with HDS to dynamically build a custom web interface based on specific program data requirements
  -  Program selection module to determine the best product for the partner
  -   Compliance module to ensure program requirements are met

Coordination among the four internal stakeholders added complexity to the project.  Meg further described more specific challenges:

• New Technology
  -  No in-house experience with rule systems
  -  Selling the importance of integrating a dynamic business rule management system to the IT Steering Committee
• Resource Constraints
  -  Small IT group
  -  Multiple large IT initiatives happening at same time
  -  Limited Business Experts
  -  Project Staff turnover
• Software Partners not local
• Selling HDS on the idea that a mature rule based engine was the best solution for the web portion of the project
• Replacement of 20 year old patched together legacy system
• Organizational Change Management Issues

Following the project overview, Meg provided sample screens, and detail on the ISIS-methodology used and collaboration tools employed in the areas of rules discovery, analysis, design, and authoring including templates and data models. She went on to describe the collaboration techniques used to keep everyone informed, empowered, and working together:

• Web seminars to demo project status
• Weekly status report to control project execution
• Create test samples with business user to test integration
• Iterative approach towards integration when changes occur
• Occasional on-site project coordination meetings

Meg concluded her presentation with the following Lessons Learned:

• Concurrent development requires special attention
• Complexity incurred by working with multiple partners can be managed with the proper collaboration tools and techniques
• It’s not just about technology
• Early training for business users is extremely valuable, especially when introducing a new way of thinking
• SOA helps manage change and works!
• Using an architecture that supports flexibility for change and interoperability is invaluable, especially when dealing with multiple partners
• Iterative approach facilitates legacy integration
• Tools and techniques are only useful with a proven methodology to implement them in a calculated and repeatable fashion

Meg noted in closing that you can not make good business decisions in a rapidly changing world without systems that support rapid change. The initial resist, fueled in part by a distrust of consultants and a history of failed projects, gave way to an appreciation of the flexibility and ease of change that business rules brings to the agency.  Given all of the factors involved in getting this project done, Meg took a conservative approach and restricted the scope of the project so that it would be manageable and provide a success experience.

In response to a question, Meg provided the following metrics

•  User manual went from 400 page to 37 pages
• Turnaround time went from as long as 60 days to as short as 10 minutes due to files not having to be held to get additional information and correct errors
  -  65% of the files in the old system were held for 60 days
• Less errors and overall compliance rate is higher

In response to a question concerning vendor selection, Meg indicated that ILOG was chosen after polling of other agencies and research. The element for this agency that made ILOG the final choice was its ability to sunrise and sunset rules.

 

ARTEMIS ALLIANCE, INC.
An information technology services firm
serving our clients for over a decade from
the warehouse district of downtown St. Paul
651-227-7172
 Wyatt Wood- wwood@artemisalliance.com