Roles in BPM applied to Business Rules

Once again, my search for anything related to governance and management brought me to the website to watch the seminar Roles on BPM at

My contention is that a lot of the concepts applicable to BPM are also applicable to business rules.

Here are some highlights of the webinar edited to apply to business rules:

It’s about the people. People are at the center of this, they make this possible.

The roles identified and their responsibilities:

  • CIO / CTO, Executive Team
    • If driving the initiative, account for metrics and high-level KPIs
    • If not, push for executive buy-in and high-level organizational support
    • Use high-level support as an opportunity for improvement across silos (COE, Governance)
  • Center of Excellence (COE) 
    •  Common location for skills, knowledge and an enterprise wide vision
  • Technology Advisory Board (Technology Councils or Think Tanks)
    • Facilitates standards and software adoptions across group
  • Industry experts
    • To help kick start the knowledge transfer within the organisation
  • Vendor support
    • To help make optimal use of the tools
  • Business Analyst, Business Rule Analyst
    • Gathering requirements, rules and performing analysis
  • Rule developer
    • Helps the Business Rule Analyst with implementation of the rules for execution
  • IT Architect
    • Responsible for the architecture and design of the enterprise system integration and configuration
  • System Developer
    • Responsible for low level development, integration with other system, etc.

Titles are less important than clear definitions of responsibilities.

Pay attention to the handoffs between roles.

Composing Project Teams

  • Business goal driven, but technology powered
  • Create mixed teams of technologists and business analysts
  • Involve and be involved with outside groups
  • Build teams for quick results but develop skills and roles for the long term

Creating your BPM team

  • Adapt to the specific project size and complexity
  • Leverage prior successes

This list of roles is a decent starting point. The information extrapolated from this webinar can also be cross referenced with the list of Roles from ABRD v1.2 (which seems a bit more complete) and other sources.

I guess I now have to take all that information and take it to the next level… You should expect more on this topic in the future.

BPM Center of Excellence applied to Business Rules

I have to admit, that recently I have been looking for anything that mentions rules governance and management, and although this center of excellence webinar by Sandy Kemsley is geared towards BPM, I think there are common pieces that can be learned from and applied to business rules.

To put it in context, the COE usually comes into play once successful projects have been completed and the lessons learned and management processes need to be expanded to have a more global point of view for the whole enterprise.

Here is an excerpt of what is mentioned about the Center of Excellence (COE) for BPM.

The benefits expected from a COE:

  • Knowledge transfer
  • Synergies between projects
  • Shared code and components for reusability
  • Faster deployments
  • Lower costs
  • Standardized, repeatable projects

Based on survey by Forrester, the presence of a COE increases the success of the projects as opposed to not having a COE.

The functions expected from the COE are:

  • Skills. The knowledge and skill set is too rare to maintain in each project
  • Governance. The COE becomes the point of convergence for governance for creating common principles and methodologies
  • Repository. A common place for keeping training material, best practices and techniques, common code and components
  • Community. A place to share and discuss ideas and do problem solving and to shift points of view from project or departmental to global and enterprise level

 To build the COE, here is what is required:

  • Executive sponsorship
  • Methodology and best practices independent of technology
  • Co-location of the people to improve communication

The roles required in a COE (which I adapted for Rules)

  • Chief “Business Rule” Officer
  • Steering committee
  • Project manager
  • Enterprise architect
  • Business Rules analyst
  • Business Rules developer
  • User Acceptance Testing (UAT) and Quality Assurance (QA)
  • Business Rules Administrator

The webinar then goes into some case studies which are also very informational. Definitely worth a look if you are interested in Centers of Excellence and Governance.

The webinar on BPM COE can be found at:

Update to ABRD published

Jerome Boyer posted on his blog about the latest update to the ABRD (Agile Business Rules Development) framework which can be downloaded at the following address.

I have used some of the contents of the previous ABRD release, although as a whole I thought it was not as good as it should have been (and yes, I know that it is meant to be improved by a community but I was not sure where it was going to go from there).

But this iteration of ABRD is better structured, and after a quick review, it seems to be of much better overall quality. As a starting point for people dealing with business rules, it might provide some insights and guidelines as to how to run a business rules project.

I only wish that contributing to it was a bit easier and more transparent and that people from companies other than ILOG would also contribute to it so that the best practices in ABRD have less of a bias.

There are still some holes and very simplistic descriptions used in some of the items, but the evolution from the first version to this one makes it a very promising tool for people that work on a business rules project.


I just listened to a webinar by ILOG that discusses the integration of the ILOG BRMS with BPM.


I am glad to see that they are starting to publicize the need for both BPM and BRMS and how they relate. This was a first from ILOG as far as I can remember.


In short, business processes should be calling business rules and this should avoid your business process to grow into something un-manageable over time since the decisions are being externalized into the BRMS.


ILOG mentions the following as reasons to separating process and rules:

  1. Increase business agility by allowing users to manage decision logic
  2. Streamline and stabilize processes by externalizing decision logic
  3. Enable re-use of decisions across different processes, applications and systems
  4. Enable automation of complex, variable decisions
  5. Effectively manage large and evolving sets of rules


The interesting thing here is that points number 2 and 3 are now presented with a business process component instead of the “application” as it used to be.


Obviously, part of the presentation was aimed at showing why IBM bought ILOG and where ILOG’s products complete IBM’s offering and how it fits with the IBM products.


Once slide I particularly liked was one where they presented their vision of the Agility Infrastructure. Which basically is presented as:


The Agility Infrastructure:

  • Detect (Business Events)
  • Orchestrate (Business Process Management)
  • Decide (Business Rules)
  • Monitor (Business Activity Monitoring)

This is a simple representation of the 4 concepts and how they relate, yet it is a very effective one.


The recorded session and slides should be available soon on the ILOG web site.

On Business Rules project best practices – Part VII – Model and Vocabulary

This entry is part 7 of 7 in the series Business Rules Project Best Practices

In the first post of this series, I started listing a list of best practices that can and should be used when working on a business rules project. This post is about detailing one of these practices further.

Of all the best practices listed so far, this is the one that I believe to be the most critical to the success of a rules project.

Why did I wait so long in the series to introduce it? Well, I could have started with it, but it is not the only best practice that needs to be considered and if the first best practice is being followed (Get help and educate yourself), hopefully the model and vocabulary will be one of the main things some external help will push for.


You can choose to skip this section and refer back to it when you encounter the word for the first time later in the article.

Before we continue with the rest of this article, it will be useful for me to provide some definitions that will be used in the article.

  • Term: a word or phrase used to describe a thing or to express a concept [1]
  • Concept: an abstract idea. Concepts are expressed by terms. [1]
  • Fact: Facts relate terms [2]
  • Fact Type: a fact type is an association between two or more concepts
  • Vocabulary: the body of words used in a particular language or in a particular sphere [1]
  • Terminology: the body of terms used in a subject of study, profession, etc. [1]
  • Fact Model: A fact model establishes the basis for shared operational business knowledge. [2] This model is usually graphical and can also be called the business object model or BOM.

The business vocabulary

Let me start with the vocabulary. This refers to the language being used by the business people to do their day to day work when they refer to what they are working on. It can also be called terminology [3]. In our specific case, we are interested in the vocabulary used by the business people, so we are referring to a business vocabulary. In the article I will usually use the shorter “vocabulary”, but it means “business vocabulary”.

Why are we talking about vocabulary? Because we need to formalize this vocabulary, clarify definitions and meanings to remove as much ambiguity as possible. This vocabulary will be used to create a fact model that will be used by the rest of the project and by the rules.

This formalized vocabulary needs to be well documented, agreed upon and communicated by the business people. There needs to be a central location for the documentation of this vocabulary.

Some will ask: I know my business, so why should I document and formalize a vocabulary? The answer is simple. Not all the people working on an IT project are as knowledgeable about the business, and ambiguity or misunderstanding of terms used by the business people can have unexpected results. I will try to explain more with a couple of examples.

I once worked with a customer that was in the importing and distribution of goods. One of the first things I usually try to do is to either look for an existing vocabulary (which did not exist) or to learn about the business to start building a vocabulary.

As I was learning about their particular business, the business person I was talking to referred to a “Purchase Order” (or PO) a few times and at some point I had to stop him and ask: “When you talk about the PO, which PO are you referring to?” He looked at me with a blank stare. “Well”, I continued, “when you place an order to your SUPPLIERS, you use a PO correct?” He simply answered “Yes”. I continued “Also, when your CUSTOMERS place an order to you they use a PO, correct?” He nodded. “Well then which PO are you talking about? The supplier PO or the customer PO?”

I will spare you the rest of the conversation in which we went on to clarify the vocabulary that they were using in that particular business, but that short conversation shows how something seemingly simple sometimes requires some clarification.

Both Purchase Orders had similar attributes but they also had specific attributes that made them different. These need to be documented well in any project, but specifically in a business rules project where some rules may need to refer to Purchase Orders and in that case we may need to know which one it is.

As a second (shorter) example

On a another project that I worked on dealing with the company customers, in discussions the business people were using the terms customer and client somewhat interchangeably. We needed to clarify if they were the same thing or if they were actually different things for that system. Once again clarification of the vocabulary was required.

The point to this exercise is that we need to document, formalize and clarify a vocabulary that will be used in the project. If there is confusion about a term, go back to the vocabulary, discuss it and if required, make the necessary adjustments since it is a work of progress after all.

Building the vocabulary

The vocabulary can be built using multiple techniques, but some of the usual ones are:

  • Interviews with business people
  • Review of documentation
  • Review of current systems

The vocabulary will be a work in progress and you should not expect to build it completely before starting other work. You should start building the vocabulary with the most common terms, and eventually put it aside to come back and add or update the vocabulary as needed throughout the project. It is an incremental piece of work (sometimes tedious) but essential to the rest of your rule project.

The model

Now that we have a vocabulary that the business agrees upon, it is time to start working on the model (sometimes called a fact model). This model is used to represent the main entities from our vocabulary (if not all) and their relationships to each other. This will be a very useful tool when trying to write business rules since it will graphically show what the business and the rules are about.

Here is an example of a simple model:

It may also be used to identify gaps in the current vocabulary as I will demonstrate below.

The model on the left shows the first pass at coming up with a vocabulary and building a model from it. It became apparent that there was a concept missing and therefore the vocabulary was amended to add the term “pet” of which Dog and Cat are types. The resulting model is shown on the right.

The model can also become the starting point for other work that will be required in the project such as a data model and an object model. So we could add additional information such as multiplicity between the facts as shown below.

All of these details will give the business a common starting point when discussing anything between themselves or with other people, especially IT technical people.

The Foundation for other work

When discussing the importance of the vocabulary and model when dealing with rules, I often compare it to the foundation for a house.

Having a good foundation for a house will allow building sound structure on top. Having a good vocabulary and model will allow you to build good rules.

Adding an extension to the foundation and structure of an existing house will allow the house to evolve and fit the new needs of the owners. Similarly, it is possible to add to a good vocabulary and model and eventually to rules and it is to be expected.

The danger lies in the inappropriate foundation of a house. If the foundation for a house is inappropriate and needs to be redone without touching too much of the existing structure, it is possible, but it is complicated and costly. The house needs to be lifted of the current foundation, the current foundation need to be destroyed, the new foundation needs to be built and then the house can rest on the new foundation again.

The same goes for the vocabulary and model used for business rules. If the vocabulary and model are not done properly to start with, it will be hard work to change it later, especially if rules have already been built using them.


Should you start with the model or the vocabulary? I personally like working the model and building the vocabulary that goes with it alongside. How you decide to do it in your environment is not that important. What IS important is that you DO actually create the model and vocabulary. These will be the building blocks of the foundation for a lot more work in the future. If you don’t have it, your foundation may be too flimsy to support that future.

[1] From, oxford dictionaries

[2] Ross, Ronald G., Business Rule Concepts, 2005, Business Rules Solutions

[3] Terminology denotes a more formal discipline which systematically studies the labeling or designating of concepts particular to one or more subject fields or domains of human activity, through research and analysis of terms in context, for the purpose of documenting and promoting correct usage. From wikipedia.

On Business Rules project best practices – Part VI – Divide and Conquer

This entry is part 6 of 7 in the series Business Rules Project Best Practices

In the first post of this series, I started listing a list of best practices that can and should be used when working on a business rules project. This post is about detailing one of these practices further.

Divide and Conquer

Once you have scoped the full project size, it is now time to divide it up in to smaller pieces that are easier to manage and develop. In essence this is “Divide and Conquer”.

There are many advantages to taking this path. First, should there be enough resources available, multiple pieces of the whole might be able to be worked on in parallel. Second, each piece or phase of the project will allow teams to work on goals that are easier and faster to attain and that work toward the ultimate goal.

Working in parallel

Depending on the nature of your business rules and the availability of some key resources, it may or may not be feasible to work on parallel streams to complete multiple pieces of the project at the same time. But in some cases it might be beneficial, and when depending on the project manager and the timeline you have to respect, this may be a good option.

The only caveat I have to mention about working in parallel is that it is better to have completed the prototype or pilot before attempting this. This way, your lessons learned and knowledge from this first experience can be leveraged accordingly.

Smaller goals

The journey of a thousand miles must begin with a single step. – Chinese proverb

Working on smaller goal will help teams build confidence and knowledge on what and how to do perform the activities required to attain the goals. They may decide to readjust some of those activities based on lessons learned and the whole project will benefit from this experience. The teams and the rest of the organization will see progress and the completion of each phase will be yet another milestone towards a successful project.

How to divide and conquer?

At the project level

There are many different ways of dividing the business rules projects and how you decide to do this in your own project may differ from the following, but here are example options:

Divide by:

  • Subject Area (or domain). If the business rules in the subject areas have little or no co-relation, this may be a first level of division.
  • Sub-domain. Some domains are large and may be composed of sub-domains that may be easy to separate from each other.
  • Business Process. Depending on the size and complexity of the business processes, the business process might be an appropriate chunk to separate for a project phase.

At the rule harvesting level

Although the details of the steps to follow during a rule project will be detailed in separate posts, the rule harvesting portion of a project may also be divided into pieces depending on resources, and the number of rules. The following suggestions are inspired by a presentation made by Gladys Lam at the Business Rules Forum 2008[1].

Divide by:

  • Business Process. If the business process has few business rules within its tasks and decision points (50 rules per task)
  • Task: If there are more than 50 rules per task
  • Decision Point: If there are more than 100 rules in the tasks.

In short, if the work is broken down into smaller manageable pieces, your chances for success will be increased.

[1] Lam, Gladys S.W., Organizing a Business Rule Harvesting Project: Divide and Conquer, Presentation made at the Business Rules Forum 2008