How do organizations newly implementing the BRS methodology tackle documenting their business rules? What rules does that organization choose to document first? Using the BRS methodology there are two ways to document business rules:

1. 'green field' documenting rules on a new product before or as the rules are understood
   
   
2. harvest rules from production code

For organizations starting a rule documentation initiative, which is best? Both work, so which is 'more correct'? Which is easier to start?

Coming from a QA background and learning the BRS methodology, I originally thought that green field capturing is more correct, more ideal, and would provide a more significant benefit. Now, with 2+ years of BRS methodology under my belt, I've come to believe that harvesting production code is actually easier and more beneficial. Again, the caveat is that this is for organizations new to the BRS methodology — that don't have a business rules repository housing concept models, terms, and definitions.

Primary Benefits of Harvesting Production Code

• Fact-based work: Production code is known, at least somewhat. Staff may argue that they don't understand what's in the production code but, regardless, that production code is quantifiable and can be reverse engineered, and (like it or not) that production code is the current source of truth — whatever that may be.
  
  
• Collaboration: It forces business and IT to work together. The process of understanding and documenting the coded rules takes time and requires both roles. The organization needs to make the work a priority because it takes time. It may not be easy but should be rewarding.
  
  
• Planning: Code can be decomposed. Chunking the code makes tackling it more quantifiable — easier to understand the scope of the work, which helps planning.
  
  
• Scope is contained: It limits scope creep. The code is what it is. The scope of the task is to document the rules as they're coded.
  
  
• New insights: Additional requirements may come out of the harvesting and this is good. Understanding what's in production may provide the business or IT team with new ideas. These ideas can be handled separately, but it was the review that may prompt better ways to implement the code or ideas for enhancements.
  
  
• Uncover hidden faults: The code may hold some surprises. For example, a team discovered a missing business rule and was able to assess and proactively correct the problem before it surfaced and was reported by customers. Another team shared their harvested rules with a committee who found a rule that was implemented differently than expected. Once the committee went back to the original guide book they found a flaw; too much room for interpretation. This was an opportunity to correct the original guide book, and the project team was able to change the code to match.

There are many benefits to a business rules repository with documented business rules. Harvesting coded rules can take time, but the benefits are likely much greater than initially anticipated.

# # #