Business Rules Governance and Management – Part V – Roles

This entry is part 5 of 10 in the series Business Rules Governance and Management

After the “interruption” by the October Rules Fest and the Business Rules Forum, I am continuing the series on Governance and Management…

This post is part of a series on Business Rules Governance and Management for which the main article can be found here.

Roles and Responsibilities

So now we have some key players from the governance and management teams and we can start the “real” work.

One of the first things that I suggest gets started is a list of Roles and Responsibilities. The reason for this is that with that list in mind it may get the key team members thinking about what tasks will eventually need to get done (Responsibilities) and who would have the responsibility (Role).

The list you will see below is strongly inspired by the “Agile Business Rules Development” (ABRD) Methodology (See References at the end of the post).

I suggest starting with this list, adapt it to your needs and make it fit with how you intend to work and your enterprise.

Also remember that Role does not necessarily equal a position (or a person) in the organization. A single individual may play multiple roles as part of his/her work with business rules. You can identify the people later, although it sometimes helps to match actual people’s names to the role or roles that this person would play.

Role Role-Responsibilities
Business Owner
  • Control the execution of a Line Of Business
CIO / CTOExecutive Team
  1. If driving the initiative, account for metrics and high-level KPIs
  2. If not, push for executive buy-in and high-level organizational support
  3. Use high-level support as an opportunity for improvement across silos (COE, Governance)
Project Manager
  • Manage the project
Policy Manager or Subject Matter Expert (SME)
  • Support the definition of business processes
  • Determine and manage the implementation of a business policy, generally by providing the content for the business rules that enforce the policy and the process contexts in which the rules are applied.
  • Oversee the execution of that policy via business rules applied. Such oversight includes confirming that implemented rules fully and faithfully correspond to the intended policy.
  • Review rules, rule flow
  • Review the results of testing and simulation
  • Manage business vocabulary
  • Resolve business issues relating to BR
  • Be accountable for the quality of the BR
  • Approve major changes to BR
Manager Or Rule Steward
  • Develop and maintain a comprehensive plan for the rule management group activities
  • Establish BR policies
  • Identify business sponsors for issues relating to BR
  • Develop processes for rule management and standards for rule capture and documentation
  • Ensure that repository management processes are followed
  • Ensure that enterprise rule standards are followed
  • Standard management position
Enterprise IT Architect
  • Select technologies that are in line with the enterprise architecture
  • Ensure that the vision for the enterprise architecture is considered
Rule Architect
  • Select technology to ensure performance and usability
  • Design, test, implement rules using appropriate technology (triggers, rule engine)
  • Ensure the overall deployment organization of the rules makes sense from an application segmentation perspective
  • Ensure rule execution is optimized
  • Establish traceability for rules within the technical architecture
  • Ensure rule reuse
  • Design the structure of the rule repository (defining what metadata customizations are needed and possibly implementing the structure)
  • Develop the processes developed around repository management
  • Assist evaluation of implementations with respect to the rules
  • Coordinate with application developers on system design, implementation and testing
  • Act as a liaison between business and IT
Rule Analyst
  • Assist business in identifying existing BR
  • Research the meaning and origin of BR
  • Create rule templates for rule authors to use
  • Analyze rules for completeness, correctness, optimization (from a logical, not performance, perspective)
  • Identify how rules are used in processes that implement business policies
  • Ensure the quality of the BR
  • Ensure consistent terminology is used in the BRs
  • Analyze BR to identify conflicts, redundancies
  • Ensure consistency of BR across function, geographies and systems
  • Conduct impact analysis for revising or replacing BR
  • Integrate new or revised rules into existing rule set
  • Make recommendations for BR changes based on business knowledge
  • Facilitate resolution of BR issues
  • Act as consultant for the project team
  • Act as a liaison between business and IT
Vocabulary Analyst
  • Formalize the business terms (and phrases) used in business rules; this formalization may be in a logical data model, fact model, business object model or some other format that standardizes the terms used and their definitions. ‘Terms’ include nouns, noun phrases and qualified nouns that are referenced in business rules
  • Create and manage abstract layer of the data model
Process Analyst
  • Define the overall process context for the business area/ application.
  • Work with business SMEs to understand the logical business processes and how they fit together in a logical flow (or in an implementation flow for a given application).
  • Identify where rules are needed in processes
  • Create and update process flow
Rule Author
  • Write detailed rules, following appropriate syntax and using standard vocabulary Validate rules in detail against the object model and data model
  • Perform impact analysis for potential changes to rules from technical perspective
  • Identify events where rules should fire
  • Challenge BR for ambiguity, inconsistency and conflict from a technical perspective
  • Test Rules
  • Create and update rule flow
  • Run simulations
  • Ensure rule reuse
  • Debug rule logic
  • Create and manage test cases to test the rule logic
Business Analyst
  • Understand business goals
  • Find business solutions to business problems
  • Ensure business solutions support business goals
  • Make recommendations for business change based on business knowledge
  • Conduct impact analysis of proposed business changes
  • Identify and assess business tactics and associated risks
  • Facilitate meetings to gather business requirements
  • Document “as-is” and “to be” workflows
  • Record terminology, business concepts and fact model
  • Capture and express business rules
  • Analyze BR, identifying conflicts, redundancies
  • Decompose BR to atomic level
  • Act as business team lead for the project team
  • Act as a liaison between business and IT
  • Understand business rules methodology and how to apply it
  • Develop application business logic, database access layer, GUI
  • Domain object model
  • Meet functional specs
  • Write technical rules in low level ILOG Rules Language
  • Set rule project foundations:
    • Rule project structure
    • rule set parameters
    • rule flow
    • sandbox testing in Rule Studio
    • Develop the BOM to XOM mapping
  • May have rule management requirements if rules are primarily technical rather than business-managed
UAT Tester
  • Business tester
  • Performs final testing of the application by performing relevant business scenarios to determine if the system tested will satisfy the real world business needs
  • Sign off of the rules implementation
QA engineer
  • Manage application and rule set quality
  • Develop Rule Test cases
  • Define Key Performance Indicator with the Policy manager
Rule Repository Administrator
  • Manage the different rule repository cross departments
  • Develop the standards that are required across projects
  • Manage the rule deployment and rule set quality
  • Install and configure environment
  • Deploy the application
  • Re-deploy rulesets as changes are made
  • User management (security)
IT Operations
  • Monitoring Business Rules Execution
  • Reporting statistical use of business rules
  • Making sure everything is running smoothly

To put things in a more “Visual” Perspective, I also have created a graph shown below that depicts the roles mentioned above, but classified along 2 dimensions: production-management and business-technical.

The Production-Management dimension simply shows how close to management or to actual operations and production the roles are.

The Business-Technical dimension shows how technical the role is expected to be or how pure business the role is.

Once again, these are subject to interpretation (even I can’t seem to agree with myself on the exact position for each role) but it serves as a visual indicator of what kind of person should be filling-in the role in question.


Adding Skills

Once we have to Roles and Responsibilities well identified, a list of skills can be developed for each role. This list of skills can range from the technical skills required for the product to the management skills that are required by a specific role.

This list of skills can then eventually be used to build a training plan so that when specific people are associated to the roles, there is also a starting point for building a training plan to make sure the person has all the skills required to fulfill his or her role.

The table available in ABRD actually supplies a list of skills for the roles and can be used as a starting point for filling in your own list of skills.

Next, we will be looking at some of the Management pieces we need to focus on. We will start with the Rule Life Cycle.


Agile Business Rules Development, ABRD v1.2, available at

Business Rules Forum 2008 presentation, Benefits of a Business Rule Management Tool/Repository and Not a Requirements Management Tool, by Shikha Khan, Single Family CMO Rules Management, October 29, 2008

Roles in BPM applied to Business Rules,

Series Navigation<< Business Rules Governance and Management – Part IV – StakeholdersBusiness Rules Governance and management – Part VI – Rule Life Cycle >>

Leave a Reply

Your email address will not be published. Required fields are marked *