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,

#BRF Emerging Trends & Decisioning Panel

This entry is part 23 of 24 in the series Business Rules Forum 2009

Roger Burlton, James Taylor, Sandy Kemsley and Ronald G. Ross as panellists for this session. Kristen Seer is moderating.

KS: This our chance to look forward. Introduce yourself and what are the trends you are seeing in your specialty.

RB: Ideas are revolutionary, but implementation is still evolutionary. First pattern is treatment of BP as enterprise assets. Strong trend towards governance over performance to support change. Strong drive towards frameworks.

JT: Early days for Decisions to be enterprise assets. Rules and Decisioning more and more in enterprise applications. Extend to which rules are considered more and more important by analytics. Decisions against streaming data (event processing?) is coming, but not sure.

SK: More and more collaboration between rules, analytics, processes, analytics and BI. Support for unstructured processes is becoming more visible and more important. Give people goals and give them what they need to fill those goals. Give people more flexibility in how they are solving problems.

RR: Evolution over the last 12 years (of the conference) shifts “What is a Rule” to “How do we do this?”. The real challenge remains a people challenge and the ability of communication and the importance of that has. He has concerns about the people who will have to have the skills to take this forward, especially in Business Analysts.

Eric Charpentier: Convergence of Rules, Processes, CEP, Analytics, etc. Are we going to see a merge or stronger collaboration in the future?

RR: Very high probability that there will be a Process conference co-located with BRF in the future. Honestly think that we are at the stage where we need to know all the parts to the solution to business problems

RB: You can’t use a single interdisciplinary approach to solving multi faceted problems and need all the tools to solve that problem.

RR: (basically agrees with RB).

Audience: Relationship of BA.

SK: Organisations are moving people to BA positions because they were good business users, but it should go beyond that and we should see a certification for BAs to make sure that they have some of those skills required for BAs similarly to a company hiring a PM with a PMP certifications

JT: For Analytics, we see adoption only in companies with strong background in math. It is difficult to convince people of the different

RB: In Canada, there is a consultant organisation and a certification for management consultants.

RR: The most important skill is to relearn how to speak business instead of IT. It is very difficult to get people to speak “normal language”.

SK: Changing roles of the BAs because things are done differently today. Still a lot of waterfall approach and we won’t be able to build agile systems with that approach, we need to bring in agile methodologies to help.

RR: For entertainment, will disagree with SK. If you write the BR precisely enough, you have eliminated so much ambiguity that you have possibly “eliminated” testing in the traditional IT sense.

RB: The testing is built in to a very agile style, so we are doing it but in a smarter different way.

JT: Design time structures changes drastically how things are done. We need to educate the IT colleagues on what the tools surrounding DM can do.


JT: Business people think about the impact analysis to make sure the rules are doing what they should. Testing is a very “overloaded” word.

RB: In the methodology it is called Validation, not testing.

RR: Business Rules are what the business needs, Non functional requirements are for the systems, not the business.

Audience: To what degree will the aggregation of tools will influence the methodologies and standards?

JT: Some of the BPM standards are not talking about Rules or decisions at all. But BPM vendors support them. But as people are actually doing projects they see the need for this convergence and as more projects are being done the feedback will drive this convergence even more.

RB: Standards are being developed by vendors who can afford to pay people full time, so practitioners are not involved in the development

RR: Agree with RB 110%, but don’t wait for standards.

SK: Standards are also becoming so complex and BAs just don’t get them and shouldn’t need to understand them.

RB: Some of the BPMN events are becoming so complex that it is becoming a programming language. Which is why BPMN light is there to keep things simpler.

RR: SBVR is coming, but the timeline is about 10 years from now.

RB: Congratulates RR on the Business Motivation Model.

RR: (sorry Ron, I missed your comment)

Audience: Will we see more focus on BAs as opposed to IT in the rules conference?

SK: We saw that in BPM conferences that used to have a lot more men before, but as time advances, more and more women come to these conferences because they address more and more the Business people.

RR: Given the range of problems to solve, I hope we will continue to se a good mix of business and IT people.

JT: Organisations usually send IT people to technology conference, but have a hard time sending BAs, but we need to shift that thinking so that BAs can attend.

RB: (sorry missed the answer)

RR: Any and all suggestions will be welcome to solving this issue.

SK: It’s all about the contents of the conference and how you can relate to who is presenting and what is being discussed.

Audience: Is there something we can tell the business to be a better business

RB: The business needs to be performance centric.

JT: Tell people to not be focused too much on their own vertical and that should be open to learning from other verticals because they can still relate to some of the solutions being used.

RB: A process that was developed for the hotel industry was patented and can actually be used by other franchise industries, cross industry but useful.

RR: ()

Audience: How am I going to help my employees. What are the key areas for training to be prepared?

RB: It depends on your maturity. Making sure they understand terminology the challenge and show them examples.

RR: Smart Enough Systems contains many examples that people can use to get people thinking. Same thing for Business Rules Concepts that was meant to be simple to read. “You don’t get credit for problems you solve but that others don’t perceive”. Focus on the problems that the company perceives.

End of panel.

#BRF How business rules and processes fit together

This entry is part 22 of 24 in the series Business Rules Forum 2009

Dr. Jan Vathienen is presenting.

There is always a problem to transform business vocabulary, business rules and business processes to IT. We want to build flexible system and compliant with the rules. How do you organize processes so that they are and remain compliant.

This flexibility can be obtained by supporting all the possible changes.

There are multiple levels of compliance:

  • Be Compliant
  • Prove that you are compliant
  • Be compliant after a change
  • Remain compliant after every change
  • Prove that you remain compliant after a change

Flexibility, alignment and compliance with the business. Flexibility is offered by the SOA architecture. How do you remain compliant in rules? When rules change the process may have to change.

He then took some time to show how decision trees are not processes, and how you can improve on that and make it more flexible as a process. There are 2 types of rules in processes:

  • decision points
  • decision service

But also there are other rules (timing, access rules, audit rules, …). There are also other implicit rules that can be hidden within the process.

Business Rules are the “GPS” of the Business Process –Dr. Vathienen

He also showed a classification of rules and how these types of rules can be used to simplify a typical process diagram. He simplified the diagram so much in his example that he made the original diagram useless.

“A process diagram is nothing more than a visualisation of the rules.” –Dr. Vathienen

He proposes that it is possible to start from a couple of simple rule statements and to generate processes. So every change in the rules will allow you to re-generate processes automatically and all of this will make sure that you remain compliant as long as you rules are compliant.

Process modeling and enforcement is on a scale from static and procedural to dynamic and declarative. The reality is that we are somewhere in the middle with fixed processes but declarative rules.

He then showed that Business Process Management and Business Rules Management are actually 2 sides of the same coin:

  • Modeling
  • Enactment
  • BAM (vs Rule Activity Monitoring)
  • Execution
  • Maturity

I actually like this slide because it does show some gaps that we are not doing on the rules side that is done with Business Processes.

He linked this to an architecture for business rules, events and services.

Sandy Kemsley actually saw this presentation (or something very similar) about 2 years ago, see:

My thoughts? Interesting, but seems still very academic for the time being.


Funny Excerpt form the Q&A part:

Audience: The business rules manifesto says that rules are first class citizens, but what you are proposing here seems to indicate the the rule are King!

Dr. Vathienen: In a presentation you always have to exaggerate a little, so maybe not King, but Queen!

#BRF Standards for Business Rules

This entry is part 21 of 24 in the series Business Rules Forum 2009

John Hall is talking about the state of the standards around business rules.

I had originally thought of blogging this session as I had done the others, but I think it won’t necessarily work well because of the topic.

Instead I will list the standards (and eventually add links to their respective standards) that were discussed.

  • BMM
  • SBVR
  • PRR
  • ODM
  • RIF
  • XBRL
  • UML
  • OSM
  • IMM

And more but it is unknown how they really fit:

  • ISO-704
  • ISO-1087
  • ORM: Object Role Modeling
  • CL (Common Logic)
  • OWL
  • RDF and RDFS
  • RuleML
  • JSR-94 (Purely API definitions)

The slides that do with this presentation are obviously helping a great deal in understanding the relationships between the standards.

#BRF Business Event Driven Enterprises Rule!

This entry is part 20 of 24 in the series Business Rules Forum 2009

Brian Dickinson of Logical Conclusions is leading this session.

He explains his own definition of events (being an author) and says that he is happy to see how many talks mention events at this conference. Being an event driven enterprise will set you apart from your competition.

An event is anything that happens beyond the are of study that requires or produces a response inside the area of study. – B. Dickinson

All systems have a stimulus-response mechanism. Events make the world go round. In one process view the world consists of a mass of things (events) happening through time. We select the ones we are interested in (sounds like patterns to me).

In the business world and event is what it wishes to respond to from the outside world. The enterprise has no control over theses external customer event, it simply responds to the arrival of the stimuli from the events.

Each external need to which we respond is called an event. An enterprise’s response to an event is a 3 tiered structure: selected events, business analysis, system design and implementation.

There has been a fragmentation of the systems at the implementation which created boundaries at the design level based on the departments, but that is not how things should. The groupings were based on skills of the people that needed the systems.

The boundaries are “historical” (he used hysterical) and using events should allow business to see through these old and outdated boundaries. Engineering the enterprise should be based on events.

Flavors of event:

  • Business Events: to which the business wishes to respond
  • Dependant Events: to which and enterprise responds to satisfy its business events
  • Regulatory Events: To which an enterprise is required to respond

System events are invented at design time. Strategic events are those that dictate the contents of the enterprise’s policy.

Gather 6 things for analysis of events

  • Source
  • Stimulus
  • Processing
  • Memory
  • Response
  • Recipient

You can get rid of “files”  if there is not “intersection” between 2 events.

Let the “data” flow through with no slow down and do your analysis to allow this. The boundaries should not slow down the processing of the events.

If it takes more than “minutes” to get through your company, he says that you are not using event driven partitioning. Don’t combine events, Don’t break events.

Very interesting talk although I wish it would have been longer because we barely skimmed the surface of his topic.

#BRF Keynote: Smarter Systems for Uncertain Times

This entry is part 19 of 24 in the series Business Rules Forum 2009

James Taylor his giving the keynote this morning at the Business Rules Forum. No slides, just talk.

Why do you need a smarter system, what is a smarter system?

The pace of change is one of the drivers for creating smarter systems. Changes are so quick nowadays you need to find new ways of doing things.

The competitive environment is also a driver for smarter systems. For example the amazon infrastructure to sell used books is creating competition for the second hand book stores.

Why systems need to be smarter as opposed to smarter organizations and people?

  • Volume: Volume involved in the modern business (transactions or interactions) is so high that there is no way to do this without a system
  • Speed: The amount of data in real time is huge, so only a snapshot is usually looked at because things are happening too quickly. Need to analyze data in real time to identify patterns to respond in real time.
  • Complexity:The environment we work in is getting more complex all the time

What IS a smarter system

  • Action oriented: Not passive supporters. The system needs to enable actions to be taken (either by automating or enabling people to take action) or to make decisions.
  • Flexible (in a business sense): The fact that a business person feels that the system is flexible enough to respond quickly to their needs for change.
  • Forward looking: This links what was essentially Rules driven into Predictive Analytics to peer in the future to help flexible.
  • Learn: A good decision today might be a bad decision tomorrow. Enable you to test and learn an challenge decisions so that you can improve.

How do you get there?

  • It is an approach not a technology platform with a focus on decisions
    • Discover what the processes and decisions are
    • Create decision services. Externalize the rules (Action oriented and flexible)
    • Institute on-going decision analysis to make sure you improve over time

#BRF Semantic Business Management

This entry is part 18 of 24 in the series Business Rules Forum 2009

Paul Haley of Automata is leading this breakfast session.

Forecasting beyond business rules (5-15 years) these will become indistinguishable in the future. He calls this the Business Stack.

  • Model driven architecture
  • Service oriented architecture
  • Complex event processing
  • Business Process modeling
  • Business Activity Monitoring
  • Predictive analytics
  • Business Intelligence
  • Corporate performance management

A focus on semantics will drastically change the way things will be done in the future. Ontologies will become the model. We will define things in ontologies.

He mentions FOAF (Friend of a Friend) as being a standard for exchanging data.

Business rule realities

  • Derived from AI
  • Primarily based on production rules
  • Substantially forward chaining, goals rarely explicit, no automatic sub-goaling
  • No ability to solve problems or optimize solutions
  • Not enough Ai or operations research

Comment from the audience is that “Constraint Programming does allow for some of the problem resolution that this highlights as not being addressed”, Paul Haley agreed, also “Decision Management generalizes this and includes other technologies which can be used to resolved those problems and that 90% of rules are solved using sequential algorithms as opposed to Rete or others”.

Paul Haley thinks that usually Decision Management is only focused on rules that are part of decision point in a process, but that vision of rules is very limited. (paraphrased)

Paul says that rules in natural language such as “Only full page ads may run on the last page of the Times” but he thinks that computers will eventually ask the questions required to disambiguate the rule statement. He says the “logic systems” will get past this limitation.

Semantic technology (the next step):

  • Semantics – focus on meaning (not structure)
  • Resource Description Format (RDF)
    • Graphs are the universal data structure
    • Metadata is just more data in the graph
    • World-wide identification of nodes, links
  • More powerful, logical deductions
    • Description logic (OWL-DL)
    • Logic programming (Prolog)
    • Predicate calculus (first-order logic)
    • HiLog (higher-order syntax for FOL)
  • More powerful ontology (OWL)

He quickly covered PRR but thinks it has no real added value. OMG’s SBVR on the other hand is very interesting, it is a step ion the right direction but not all the way where he thinks it needs to be. He also mentioned W3C RIF.

He continued by highlighting some of the problems with BI, BOM CEP, BAM, PA, BI and CPM. Basically missing an ontology for all of this.

A Decision is a Process AND an Event. You actually need both.

Ontology needed for:

  • BPMN
  • BMM
  • Rules, Process and Motivation

Sharing ontology across the Business Stack is key.

Somewhat controversial discussion based on the discussions that took place, seems to be an “academic” approach, but still interesting to hear.

#BRF Business Rules and Business Events

This entry is part 17 of 24 in the series Business Rules Forum 2009

Paul Vincent is talking about how CEP can help with Business Rules.

His Disclaimer: CEP technologies work alongside other (BPM, SOA, BRE) technologies

Tibco (The Information Bus Company!) is known more for EAI, but has evolved to BPM, CEP, Predictive analytics, etc.

Paul referred to other sessions or keynotes from leading analysts from Gartner, Forrester and IDC from this conference mentioning CEP as one of the key technologies that will be used more in the future.

He did a quick review of what Ron Ross’ definition of rules, or what they can be. CEP becomes interesting for timings and triggers. Chances are it will be a combination of the different types.

Rules are defined through terms and facts, some facts may be events and the rules are enforced as events occur. We want to predict when rules will get broken. It is more important to know that your a heading to bankruptcy, not that you are bankrupt (It’s too late).

Mapping for business rules to processes and decision is easier from an event perspective. He then took some time to how how closely all of the technologies (BPM, Rules, CEP) are closely related and that processes are actually aggregating events.

CEP provides a quicker response to detect issues. It shortens the time between the business event and the action that need to be taken.

Decisions are event driven, CEP identifies patterns in real time. Decisions share data and event so why keep the data in a separate system? Before it was too complex, but now CEP allows to do that to maximize performance. “All decisions are event driven”.

He showed us an example architecture for Real-time event processing. He also presented different high level design patterns that contrast SOA and EDA. A lot of the diagrams presented these concepts and I just can’t blog that kind of information.


  • Business Rules are used in CEP applications
    • Sense and respond
    • Track and trace
    • Situation awareness
  • Users should model events independently