Business Rules Governance and Management – Part X – Best Practices

This entry is part 10 of 10 in the series Business Rules 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.

In previous posts, I have discussed almost all the topics I wanted to cover (so far) concerning Business Rules Governance and Management. This last post will look at the challenges to expect and some best practices.


At DIALOG08, Pierre Berlandier made a presentation on the Challenges expected when implementing Business Rules Governance and Management Processes.

Here are a few :

  1. Staffing of the various roles
    • Staffing of roles is not considered a priority initially
    • Workers are performing other tasks at the same time (multi-tasking)
    • Mitigation:
    • Have a plan with realistic resource availability
    • Have staffing specific tasks in the plan
  2. Internal politics
    • The new, closer relationship between IT and business is difficult to manage
    • Mitigation:
    • This is one of the key benefits of having appropriate governance in place
    • Need to build mutual trust by having appropriate processes in place, and having well defined roles and responsibilities
  3. Lack of BRMS experience
    • Mitigation:
    • Hire outside help and take an incremental approach
    • Train your staff

Best Practices

James Taylor wrote a blog post called “Governance Change Control And Rules” based on a presentation he saw at DIALOG09.

Below is a list of the takeaways from the panel.

There are many things that can help improve the results of a governance implementation in a company. Some of these have been identified by different sources and are reported here to put emphasis on key items that will help implanting the governance process.

  • Executive sponsorship and active evangelism are key
  • Build expertise – centers of excellence – within the groups that are managing rules
  • Start early and iterate the process as you learn more
  • One size will not fit all – be flexible, classify different kinds of rule change and manage them differently
  • Give rule change authority to the people who are expert in the policy
  • People and process matter far more than tools


From, by James Taylor

Live from DIALOG – Best Practices in Rule Governance, Blog Post by James Taylor On a Presentation By Pierre Berlandier at DIALOG08

Business Rules Governance and Management – Part IX – Center of Excellence

This entry is part 9 of 10 in the series Business Rules 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.

In previous posts I covered most of the main points relating to Business Rules Governance and Management.

I now want to put all of this work into context with an even bigger picture in mind.

Most of the business rules implementation will come through an initiative that is part of a project. An IT Project will look at what it needs to accomplish, do some research, decide they need a Business Rules Management System (BRMS) and implement one as part of the project.

The next phase will come when they are delivering the project and need to pass on the responsibility of the rules to operations in the organization. The need for management processes and governance is greater at that time and the work discussed as part of this series of posts is performed.


In the meantime, or as part of a separate project in the organization, another initiative that uses business rules is started. They had seen the success and benefits of the first business rules initiative and decided to start using the same approach. Eventually this new project will also need to instill management and governance processes.


As one can imagine, the evolution will probably not stop there and now is the time to think about how to take it to the next level.

Enters the Center Of Excellence (CoE). The CoE is the next step that the organization will probably have to take. The CoE’s mission should be to support any project that intends to use business rules.

The CoE should be the place where:

  • Business Rules specialists (Business and Technical) are united to support projects in a consulting role
  • Training for new people can be coordinated
  • Projects look to get additional resources for execution of the project plan
  • Best practices, Management Processes, Governance Processes are developed

I have covered some of this topic in a previous post called “BPM Center of Excellence applied to Business Rules” (


Once the Center of Excellence is in place, other projects can more easily benefit from the experiences of other projects.


Although the interactions are shown as “one way” in the diagram above, in real life the interactions are expected to be bidirectional.

In the next post, we will look at some of the challenges you should anticipate as well as some best practices to hopefully make your Governance and Management initiative a successful one.

Business Rules Governance and Management – Part VIII – Access Control

This entry is part 8 of 10 in the series Business Rules 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.

In the previous article of the series, we discussed some of the more important management processes that are required for good business rules management. One of the topics that was touched on in previous articles relates to who can do what, when and the related approval processes.

Security and Access Control can end up playing a vital role in the management processes relating to business rules. There are many ways that your organization may need to control access and security but I will discuss 2 ways which should fit most organizations.

Controlling Access by Role

The list of roles created in previous steps, the life cycle of rules (states and transitions) and the processes might require that only people with specific roles are allowed to perform only specific operations.

For example, it might be unwise to let anyone push rules to production. Was the rule tested? Is it giving the right results?, etc. Similarly you may not want to let a Rule Administrator create or modify rules (their knowledge of the business and the rules might be insufficient).

Each organization will have different requirements for controlling these accesses. Each organisation will also have a very different environment in which these controls need to be implemented (from a technical point of view). It is therefore important that these topics be discussed so that appropriate control mechanisms can be put in place.

Controlling Access by Subject Area

In your organization there may be a need to limit access to specific Subject Areas or groups of rules or rulesets.

For example, all users might have the right to read all the rules, but only users from the marketing and sales area can change the business rules related to marketing and sales. Or if you have multiple product lines, you may want to limit access by product line. You may even want to break it down by rulesets within an subject area. It all depends on your organizations needs, the size of the team you are dealing with, how you are organizing work related to business rules, etc.

The Business Rules Management System (BRMS) that your organization is using should hopefully provide you with the tools or components required to fulfill your security requirements.

In the next post of the series, we will go back to a higher level view and discuss the next steps for implementation of business rules governance and management.

Business Rules Governance and Management – Part VII – Management Processes

This entry is part 7 of 10 in the series Business Rules 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.

In the previous post, I discussed the rule life cycle and mentioned that it may be a good starting point for discussions on the management processes.

We can now focus our attention to the rule management processes. The following list of processes is by no means an all encompassing list, but can definitely be used to figure out what specific processes your organization needs.

  • Rule authoring process
  • Rule testing and validation process
  • Rule deployment process
  • Rule execution monitoring
  • Rule failure management process
  • Rule retirement process
  • Rule change management process

In the following paragraphs, I will try to provide a quick description and context for the process and some questions that might need to be answered and that will hopefully help guide the development of the process. Note that some of these processes can be related to the rule life cycle discussed in the previous post. The development of the life cycle may affect these processes and vice-versa.

Rule authoring process

The Rule Authoring Process is not simply focused on the task of writing the rule. The process needs to start from the Policy people that are creating a new rule, to the analysis of that rule, to the formalization of the rule and finally to the implementation (or authoring) of the rule.

Associated questions

  • Who can come up with new rules?
  • What is the scope of the new rules (number, complexity, etc.)?
  • Who is responsible for the analysis and formalization of the rule?
  • Who is responsible for the implementation of the rule?
  • Is there an approval process before each new step can start?
  • Do we need traceability of the changes?

Rule testing and validation process

The Rule testing and validation process is there to make sure that appropriate testing gets performed for the rules that have been developed.

Associated questions

  • When can testing begin?
  • What information is required prior to testing?
  • Are simulations required? (Simulating the change over a population to evaluate the effect of the changes)
  • Is there an approval process?
  • Do we need traceability of the approvals?

Rule deployment process

Based on the rule life cycle, once the rules have been tested and validated, there should be a deployment process to put these rules in production

Associated questions

  • Where do these rules need to be deployed?
  • When should the rules be deployed? (specific day, dates, times, etc.)
  • Are these rules replacing a set of existing rules?
  • Is there an approval process?

Rule execution monitoring process

After the rules have been deployed and are executing, there is usually a process for monitoring the production environment

Associated questions

  • What are the monitoring requirements immediately after deployment?
  • Are the monitoring requirements the same after one week or one month in production?
  • What are the reporting requirements? Who are the reports sent to?
  • Example requirements: Execution statistics, Performance, warnings, non critical errors, 24/7/365, etc.

Rule failure management process

This process is one of the most important processes, and is the one you don’t want to ever have to use. What happens when there is a failure?

Associated questions

  • How are we monitoring for failures?
  • Which type and urgency of the failures?
  • What is the failure recovery process for each type of failure?
  • Who needs to be notified?
  • What is the escalation process?
  • Is support from a vendor available?

Rule retirement process

A rule or a set of rules has been in production for a while. Now it is time to remove them from production.

Associated questions

  • Who can ask for removing of rules?
  • Is there an approval process?
  • How do we make sure that only the specific rules are removed?
  • Is post-retirement testing of the remaining rules required?
  • When should this take place?
  • Where should it take place?

Rule change management process

I have listed the rule change management process separately because it can become a meta-process which will actually use some of the simpler processes detailed above.

Change management needs to take into account many situations and is probably one of the processes that will require the most work. One key point to remember is that all changes are not created equal. Some changes will require a very light process to implement whereas other changes will need a much more involved process because of the type, scope or complexity of the change.

Associated questions:

  • Who can make a change request?
  • How is the scope of the change request evaluated?
  • What is the complexity of the change?
  • What are the options depending on the scope of the change?
  • What are the approval processes?
  • What is the impact of the change (impact analysis)?
  • What needs to change exactly?
  • When is the change going to take place?
  • Are other processes leveraged from this one? (authoring, etc.)

With all of these processes discussed and documented, we are now well on our way to have a very good environment for business rules. The next post will have a quick look at the security and audit concerns.


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

Deploy Business Rules Applications Successfully, Webinar, May 28 2008, Pierre Berlandier, available at:

Business Rules Governance and management – Part VI – Rule Life Cycle

This entry is part 6 of 10 in the series Business Rules 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.

In previous posts, we have focused mainly on the topic of Governance. It is now time to start looking at the Business Rules Management aspect of things.

The Life Cycle of a Rule

Rules have a life of their own. From Birth to Death we need to have an idea of how the rule will live its life. Similarly to a person, a rule will go through many phases in its life.

Birth and Development: A human is born and from that moment on and for the years that will follow will develop in the person he will become. A rule gets created and defined.

Validation: A person will eventually go through some type of testing (either through education or simply through life) that will confirm the knowledge and skills and Make them ready for a productive working life. A rule needs to be tested and validated to confirm that it does what it is meant to do.

Working Life: A Person will usually spend a large portion of their life working doing the exact same job, at the same company (Note from the author: “Humour me!”). A rule will execute it’s work for as long as it makes sense, working night and day, relentlessly… 🙂

Retirement: At some point after a long and productive working life, a person will [choose one: be entitled, be forced] to retire from active working life and enjoy retirement. When a rule does not make sense anymore, it needs to be retired from execution.

Ok, so we now have some of the basic building blocks for our Rule Life Cycle.

As a more serious inspiration for a rule life cycle, we can look at an example Rule life cycle which is composed of the following states:

  • New: the rule is created, and can be modified by the writer
  • Ready for review: the rule writer has completed the initial work and a reviewer can now make sure that the rule is written correctly and represents the intent of the business (note: it is assumed that until the reviewer has reviewed the rule, he will work with the writer to bring the rule to the next state).
  • Reviewed: the rule has been reviewed by the reviewer is ready for the next steps
  • Ready to test: the rule is ready to test and will remain in this state during testing and until the tester either accepts or rejects the rule
  • Rejected: the rule has been tested un-successfully
  • Tested: the rule has been tested successfully
  • Ready to deploy: One last state before the rule goes into production
  • Deployed: the rule is part of a rule set deployed on production platform
  • Retired: the rule was deployed on a production platform but is no more active because it is out of date

The following diagram shows these states, the accepted transitions between states as well as which role is responsible for each transition.


This Rule Life Cycle may or may not actually be relevant to your specific situation, but the point remains that the management team needs to think about what makes sense to your situation. Create you own life cycle, and with the help of the management processes (see next post), set things up so that it works in your environment.

When creating your own life cycle, you may also want to consider the environment in which you are developing, testing and deploying these rules for execution. For example, if you have 3 environments (development, UAT, Production) versus 4 (development, QA, UAT, Production), the life cycle may be significantly different. You may also need to consider the types of rules that you have and might have slightly different life cycles based on the types of rules.

Note that the life cycle indicated above was mentioned for a rule, but it may very well be that this applies to a set of rules (ruleset).

The reason why we want to start discussing the rule life cycle is that at the same time it will force some preliminary discussions on the management processes which is the topic of the next post.


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

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,

Business Rules Governance and Management – Part IV – Stakeholders

This entry is part 4 of 10 in the series Business Rules 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.

In the previous post of this series we looked at some of the steps required to kick-off a business rules governance and management initiative. As part of the steps covered to kick things off we saw that there is a need to look at the stakeholders and how this initiative will relate to them. This post is all about that: Governance: Leadership and Communication.

From the definition:

Leadership is the ability to influence stakeholders to move towards its goal setting or goal achievement.

So we need to influence stakeholders. As a pre-requisite to that we would need to know who the stakeholders are.

I’ve been on enough projects to understand what a stakeholder is and I have done some informal identification of stakeholders before, but how can we try and take that to the next level?

Well it turns out that in the Project Management field, the latest version of the Project Management Body of Knowledge Book (PMBOK) highlights the following steps for stakeholder identification:

  • Step 1: Identify all potential stakeholders and relevant information (roles, departments, interests, knowledge levels, expectations and influence levels).
  • Step 2: Identify the potential impact or support each stakeholder could generate and classify them so as to define an approach strategy
  • Step 3: Assess how the stakeholders are likely to react or respond in various situations in order to plan how to influence them to enhance their support or mitigate potential negative impacts.

Identifying stakeholders (Step 1)

To help us with identification of stakeholders, there is an excellent reference (“The Handbook of Program Management”, by James T. Brown) which can help us:

  • Follow the money! Whoever is paying is definitely a stakeholder. Also, if the program produces savings or additional costs for an organization then the organization is also a stakeholder
  • Follow the resources. Every entity that provides resources, whether internal or external, labor or facilities, and equipment, is a stakeholder. Line managers and functional managers providing resources are stakeholders
  • Follow the deliverables. Whoever is the recipient of the product or service the program is providing is a stakeholder.
  • Follow the signatures. The individual who signs off on completion of the final product or service (or phases thereof) is a stakeholder. Note: this may or may not be the recipient referred to in the previous bullet. Often there may be more recipients than signatories.
  • Examine other programs stakeholder lists. Include active programs and completed projects.
  • Review the organizational chart to asses which parts of the organization may be stakeholders.
  • Ask team members, customers, and any other confirmed stakeholder to help you identify additional stakeholders.
  • Look for the “Unofficial People of Influence”. These may be people who are trusted by high-level leaders or who wield a lot of power through influence and not position.

Classifying stakeholders (Step 2)

The stakeholders can now be classified. There are many ways that stakeholders can be classified, the PMBOK lists a few, but it usually comes back to looking at the following dimensions: Power, interest and influence.

In an article called “Spheres of Influence”, by Rich Maltzman, Rich makes a reference to another model credited to Lucidus Consulting which uses the following axes: Attitude, Power and Interest (which effectively makes this a 3D model). I really like this model and the following questions can help (from the article):

  • Attitude: are they supportive? Are they detractors? Where do they fit on this scale?
  • Power: regardless of attitude, can they influence the project for better or for worse? In others words, what can they DO with their attitude?
  • Interest: How deeply “invested” is the stakeholder in the project’s outcome?

Plan Communication (Step 3)

Once the stakeholders have been classified using those dimensions, you can then plan appropriate actions on how to deal with each.

Each of these “personalities” for your stakeholders can be approached with a separate, special strategy.


With the tools gathered and identified above, we are in a better position to take the rest of the governance and management process forward.

From a practical standpoint, since this type of analysis of stakeholders should theoretically be part of the project management, this portion of the work is sometimes skipped or performed minimally.

The next post will look at the roles and responsibilities of the governance and management team members.


A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Fourth Edition
2008, Project Management Institute, Inc.

The Handbook of Program Management, by James T. Brown as referred to in
Identify your project stakeholders – and only then plan communications, by Rich Maltzman

Spheres of Influence, by Rich Maltzman

Business Rules Governance and Management – Part III – First Steps

This entry is part 3 of 10 in the series Business Rules 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.

In my previous article I gave definitions of Governance and Management in the context of Business Rules. In this post, I will start looking at how we can kick off the implementation of business rules governance and management in an organization.

There are basically 2 approaches to implementing this in an organization: Top down or Bottom Up. In other words, start with the Governance or start with the Management. In some organizations the choice may be imposed by the environment but I will nonetheless describe both here.

Starting with the Management

This approach may be the default approach since it sometimes comes as an afterthought to the first deployment of the business rules. The team responsible for maintaining the rules realizes that they need to organize themselves, put some processes in place, establish and clarify roles and responsibilities, etc.

Instead of planning it before, this approach is a little more reactive to the immediate needs of the team. Who needs to do what when? Processes are thrown together as a response to an immediate need because things just have to keep working.

Although I may not hold this approach as my preference, some teams may not be able to choose because of external constraints but will still succeed in pulling this together. Unfortunately it may be more difficult to introduce the governance aspects within the organization. Without the higher level support of governance, how are new roles, positions, responsibilities, training, etc. formalized within the organization?

Starting with the Governance

Hopefully in the enterprise, some people with power, influence and resources can see the benefits of starting with Governance for business rules. This approach will have the benefits of providing the team with resources to put things in place in a more pro-active fashion. With this approach, things can be planned a little and hopefully formalized a little easier.

This would be my preferred approach to implementing Business Rules Governance and Management and I will describe some of the first steps required to do so here.

The first steps

To get the ball rolling and to give an idea of how things could go, here is one vision of how things could evolve.

  1. Identify Preliminary Key Governance Team Members. Here I suggest a subset of what would be expected as a final governance “committee” because this is preliminary work and it is near impossible to be completely sure of the final structure and list of participants. In reality, it is simply the first version of the governance “committee” which will evolve over time.
  2. Identify and Classify stakeholders. This will be discussed further in a future post.
  3. Establish Communication Strategies for Stakeholders. Based on the classification made above, establish how to best approach communications with each stakeholder/stakeholder category.
  4. Identify preliminary Key Management Team members. Why preliminary? because I suggest that you identify and select key players that will play an essential role and that have the skills to help you in finalizing the roles and responsibilities. These members will play an important role in the setting up the management team and processes.
  5. Identify Roles and Responsibilities. This is going to be required as part of the organizational structure required to support business rules. There will be a future post on that topic as well.

Now that these first steps are identified and it provides a starting point for the work, the posts that will follow will provide the details associated to these first steps and the steps that will follow.

It is also important to note that the development and implementation of a governance and management process is incremental. Start small and build on experience, involving people as you need them.

The next post will discuss some of the details on identifying and classifying stakeholders.

Business Rules Governance and Management – Part II – Definitions

This entry is part 2 of 10 in the series Business Rules 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.

When working on a series, the first thing I usually like to do is to make sure the terms I use are well defined so that the readers know what context I was using them in, what the terms actually mean and to provide definitions that can then be used as a reference point for the rest of the posts. With that goal in mind, I researched the words governance and management and then tried to put them into the context of business rules.

I have found that in some articles or documents, the terms governance and management are used somewhat interchangeably but after doing the research, I wanted to make the distinctions and clarifications so that the context in which I use them is as clear as possible.

The resources I have used to build these definitions are listed at the end of the article.

There are 2 concepts that we need to define.

  • Business Rules Governance
  • Business Rules Management

The premise for this distinction is that Governance is at a higher level than Management. Management deals with the day to day operations and management of the rules. Governance deals with the stakeholders, processes, roles and responsibilities. Both work together for achieving the goal of better business rules governance and management.

Definition of business rules governance

Business rules governance relates to the establishment of leadership, organizational structures, communication and processes to ensure consistent decisions and management of business rules.

  • Leadership is the ability to influence stakeholders to move towards its goal setting or goal achievement.
  • Organizational structures; is the identification and assignment of decision rights. Roles are defined, and associated to those roles are responsibilities. Associated to those responsibilities is accountability.
  • Communication is a key role of governance. All stakeholders must be informed of the information that is relevant to them. Evangelization of the technology is also a key component of communication.
  • Processes provide the structure required for appropriate management of business rules. From processes we can identify required key performance indicators for measuring performance and appropriate control mechanisms to make sure the parties involved are doing what they are supposed to be doing.

Definition of business rules management

Business rules management relates to the activities to support the discovery, analysis, authoring, validation, and deployment of the business rules so they meet the company business goals. It is responsible for the day to day execution of the established processes associated to business rules.

  • Discovery is the identification of the rules from different sources, documentation and traceability information
  • Analysis is the analysis of the rules to make them good business rules and their organization
  • Authoring is the actual implementation of the rules in the BRMS being used
  • Validation is the testing of the rules to make sure the outcome of the rules is as expected
  • Deployment is the deployment of the rules to User Acceptance Testing (UAT) and eventually production environments as well as any other steps to consider once the rules are deployed.

A Word on Steward/Stewardship

In some discussions, some will use the words steward and stewardship. The Merriam-Webster dictionary defines Stewardship as “The conducting, supervising, or managing of something; especially : the careful and responsible management of something entrusted to one’s care”

I usually think of a Rule Steward as the Lead of the Rule Management Team as well as the Representative of the Rule Management Team on the Rule Governance Team.

In other words, the Rule Steward is involved in all things related to Business Rules.

With the concepts better defined, I can now proceed with the rest of the topic. Next, we will have a look at the first steps.


Wikipedia page:

Towards Business Rule Stewardship and Governance,
by Brian Stucky (former Enterprise Rule Steward, Freddie Mac), Monday July 31, 2006

Do you know your business policy change templates?
by Pierre Berlandier

IBM Redbook, Implementing Technology to Support SOA Governance and Management

Business Rules Governance and Management – Part I

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

Well, they are finally coming. My blog posts on Business Rules Governance and Management.

These posts have been a long time coming because I needed to do some research first, gathering information from different sources and analyzing them so that I could then write about the topic feeling somewhat knowledgeable.

This will be a multi-part series that will be broken down to limit the size of the posts and hopefully encourage readers to comment and discuss the posts.

The topics will be broken down like this:

  • Definition of Business Rules Governance and Management
  • Governance: The first steps
  • Governance: Leadership and communications
  • Governance: Roles and Responsibilities
  • Management: Rule Life Cycle
  • Management: Management Processes
  • Management: Security and Access Control
  • Governance and Management: What Comes Next: The Center Of Excellence
  • Governance: Challenges and Best Practices

I hope readers will participate in discussions so that our collective knowledge and experience can be of use to others interested in the topic.

Next Stop: Definitions!