Last time I discussed how we got support and help for our project — to build an online credit system to approve online b2b transactions.^[1]  The next step called for documenting and coding the system.

Document & Code

Documenting and coding our system entailed these tasks:

1. Provide a high-level overview in layman terms (by the business).
   
   
2. Develop the Business Requirements Document and recommend different options for approval (by the business analyst).
   
   
3. Practice (and believe in) extreme programming.
   
   
4. Learn, collaborate, and make it fun.

Give the team a mini-celebration for being brave (or naïve) for getting this far!  This is the exciting part for the business experts, who will lead this stage by architecting the core structure of the project.  Brainstorm — write down all the steps, from beginning to end, without worrying about the technology side.  Trust your instincts, and plug any gaps you feel are missing.

The next step is to simplify — sort and group business logic into several high-level categories.  Grouping into several manageable categories will have a significant impact going forward, in terms of control and monitoring.  Note that naming conventions were never really a factor here because each business is unique and different.

We identified rules that were critical to the business; these included:  criteria validations, multipliers, discounts, aggregations, and calculations.  One note about data requirements — a Business Rules Engine (BRE) is great at executing and processing rules but generally should not be utilized to query databases to retrieve data.  Retrieval of data that includes cleansing or normalizing should be an exercise done outside of the BRE, in order to focus strictly on business rules.  Patience (and lots of coffee) with a focus on simplification led us to develop five major categories.  This was a major event; flash forward ten years — simplification helped to explain the model easily and identify weaknesses and strengths.

With the high-level structure in place and an understanding of where to place the rules, the creation of the Business Requirements Documentation (BRD) by the business analyst was fast and not too complicated.  Furthermore, a walk-through of the logic and sequence of rules under each category led to only some minor adjustments.  In general, calculations, formulas, and business logic were all sequential and followed a set process.  Another refinement that paid dividends was reason codes, which serve as audit trails for each rule. Reason codes should be attached to critical rules, calculations, and business logic in order to track and count each occurrence.  Business intelligence, performance analysis, and quality assurance checks would be impossible without audit trails.

Finding a BRE developer was not easy because demand was high while supply was short.  Luckily, the project was interesting and we were able to cycle through several consultants until we hit gold.  Being a good fit with the rest of the team, along with flexibility to trust the business to lead and make most of the decisions, were key to finding the correct developer.  Besides being extremely bright, our developer (Sean) was funny, trusting, and loved challenges.  Sean encouraged us to practice "extreme programming" — we reviewed the actual code right after he was done and tested it to see if the results were as expected.  The collaborative effort paid off as the business side focused on testing the more complex rules and calculations, and provided insight on errors to fix.

Challenges and an ability to solve problems as a team helped to strengthen the relationship among team members.  While each team member had a unique expertise or skillset, having fun and focusing on learning relaxed us and reduced the pressures of deadlines and internal politics.

The next step after documenting and coding was to test and retest.  This will be covered in the next instalment.

References

[1]  Dencie Mascarenas, "Experiences in Re-Inventing a Business Process with Business Rules (Part 2): Get Support & Help," Business Rules Journal, Vol. 12, No. 1 (Jan. 2011), URL: http://www.BRCommunity.com/a2011/b575.html

# # #