As it was to be expected, Carol-Ann Matignon’s post brought some reactions from which I extracted the following definition for Decision Management.
Decision Management: The ecosystem of technologies that contribute to solving decision making challenges (decision automation) and the management of those decisions. The ecosystem includes Complex Event Processing, Business Processes, Business Rules, Predictive Models, Optimization, etc.
I think I will be adding those definitions to my definitions page…
Carol-Ann Matignon posted her attempt at demystifying the terms CEP, BPM and BRMS here. It is a very interesting post in which she makes an analogy to the human body’s functions as a comparison and a helper to understanding her definitions. That post is worth the read, but I will quote here definitions here:
The CEP / BPM / BRMS world seems fairly simple after all:
- CEP module receives or intercepts a flurry of events and processes them with the objective of figuring out what those events are relevant for; it triggers the appropriate business processes or decision services
- BPM module receives the request for a given process to be applied to a higher level entity (an application, a document…); it automates the steps defined in the business process
- BRMS module is invoked with a given context to apply business rules; it makes a business decision
Well has it happens, on the day where I wrote my first post of this subject, Ismael Ghalimi added a post of his own on XPDL and “Why XPDL is essentially useless”.
In this post, he explains why he thinks that the XPDL standard is interesting, but not as useful as it could have been. In essence, the XPDL standard is used to describe how a business process model is saved in a format that makes it possible to exchange between products, but it lacks the ability to standardize the executable portion of the diagram which then makes it impossible to exchange the executable pieces from one product to another. In his words:
“As such, it cannot be used to store and exchange fully executable processes, but rather skeletons of processes to which muscles must be added for them to run.”
In other words, the standard does not prevent vendor lock in (which is one of the main reasons why customers want this compatibility in the first place) because the executable pieces of the process will be vendor specific.
Based on his article, the combination of BPMN and BPEL is the only way to actually avoid some of the vendor lock in. BPEL (although it has limited BPMN support) does allow for some vendors to be able to exchange the executable processes.
So contrary to what I was saying in my previous post, Is BPEL Obsolete? Maybe not after all. I guess we will have to wait and see how all of these standards evolve.
 Why XPDL is essentially useless by Ismael Ghalimi
I don’t know if it was just me, but for a while I was very confused about the relationship between BPMN (Business Process Modeling Notation) and BPEL (Business Process Execution Language).
So I decided to so a quick search on the subject and to write out what I found here.
- BPMN is a way for business analysts to describe business processes using a standardized graphical representation
- BPEL is an executable language for specifying interactions with Web Services (exclusively) and is executed by a BPEL execution engine
So BPMN is geared towards business users, the graphical notation is more familiar to them. BPEL is used by developers and is not considered business user friendly.
BPMN diagrams can actually be converted to BPEL although there are some limitations as to what BPEL can actually implement, so it is possible to create diagrams in BPMN that can’t be converted to BPEL.
As I was reading more on the subject I found that XPDL (XML Process Definition Language) might actually be part of the answer to that problem.
And as opposed to BPEL, XPDL can actually represent everything from BPMN. So then the relationship would be to go from BPMN to XPDL to BPEL.
Sandy Kemsley has an interesting post on the subject of XMPL and BPEL, and according to her, the only reason to go to BPEL would be if your BPM Engine actually used that format. But XPDL would allow you to take your BPMN diagram and convert it to the format used by your specific BPM Engine (no need to use BPEL).
So is BPEL obsolete? It might be heading that way unless your BPM Engine uses it specifically for execution. As long as vendors have support for XPDL it should be possible to export and import processes from one product to another.
Here are some of the interesting articles I found that might be useful if you are interested in the subject.
XPDL and BPEL by Sandy Kemsley
BPMN-BPEL in Perspective by Bruce Silver
Why BPEL is not the holy grail for BPM by Pierre Vigneras
Why all this matters by Ismael Ghalimi
WfMC counters XPDL criticism, argues three standards count
 BPMN FAQ at http://www.bpmn.org/Documents/FAQ.htm
Some time ago, I was asked by someone the difference between business rules and requirements. My initial response was to say that business rules are meant to change faster than requirements and that the tools used to manage requirements might not be the best tool to manage rules.
That answer was sufficient at the time but I wanted to refine this answer a little bit and decided to do a little research on the subject and to report my findings here.
An updated answer would now be along these lines:
- Requirements tell you what the application should be doing. It will be using processes and business rules because the combination of all three will give you what you need to know how a business works. These have a tendency to be relatively stable over time for a given system.
- Processes are the steps the business will need to take to achieve a goal. It is supported by decisions which are in business rules. These can change occasionally when there is a need for an updated (or new) process to achieve a goal, or if the goal changes.
- Business rules define the policies that constrain the business (and its processes). Business rules can change independently and much more often than processes and requirements.
In addition to that I would mention that they are all related, but are different enough that the tools to manage each of those are different. Also, separating the business rules out of processes and requirements will position them for change.
The techniques to gather the information on requirements, are also similar although some techniques are better than others at obtaining results.
During my search for more information I found a couple of very interesting articles on the topic.
Live from Business Rules Forum (almost) – Getting It Right. Rules and Requirements in Software by James Taylor
Why Separate Rules from Requirements by Scott Sehlhorst
 Elicitation Techniques for Processes, Rules, and Requirements by Scott Sehlhorst
Daniel Selman added an interesting post to his blog discussing the “Meet in the middle” approach which is a combination of top-down and bottom up. You can see the original post here.
I commented on the posts on his site, but I will reproduce one of those comments here. Enjoy
Meeting in the middle challenges
The challenges I have seen with this kind of approach is that if you are working on a project that is using the Zachman Framework, chances are the people working on the modeling (conceptual and logical data modeling) are not the same as the people who are working on the rules and who need to help the Subject Matter Experts work with rules. The model that data modelers will propose will most probably be different than what a model created for the business (and business rules) needs to be and therein lies the challenge of trying to steer the modeling in the direction required for the rules.
What I have seen is that the data modelers want to use best practices of their world which is great, but the vocabulary that they will create will be inevitably different than what the SMEs are used to in that business. For example, they will use some data modeling patterns (party-role for example) but these are not terms that the business uses. So what is the relationship between the models? Is there a relationship?
The solution? I’m not sure.
Does a completely separate modeling effort need to take place? And then an effort to try and map one to the other (i.e. map the business object model to the logical data model using view or some other technique)? Both models will end up influencing the other in the end, so changes are inevitable, but is it better to use that approach?
Or should the team try to collaborate on creating a model that will work for both purposes? This requires that both modelers (assuming there is one for the data modeling world and one for the BOM) collaborate and educate each other on reasons why they should go one way or another. Will you end up with 2 separate models anyway in that case?
There may be other solutions to this and hopefully we will see other people’s input to this.
My background is focused mainly on business rules. But as I have been reading more on the subject and have been expanding my knowledge, I was seeing more and more topics touching on business processes. The more I read about it the more I find that I should have caught that relationship or at least the implications of that relationship much sooner.
The business uses processes to perform its work. Business Rules are there to support the processes. The relationship has been there for a long time, but I suppose that my exposure to business rules through products that were mostly business rules oriented, I had been blind to the connection.
As I was reflecting more on the subject, it seems to me that one can’t work well without the other, so I started exposing myself more to the business process side of things.
My visit to the Business Rules Forum in october 2008 also confirmed that this is something that a lot of people are connecting together and a lot of the talks touched on the subject. One of the talks (and then I saw that reference used many other times during the conference) referred to the fact that business has been using the terms “Policies and Procedures” for a long time. Procedures being the business process aspect, policies being the business rules aspect. Why didn’t I see that before?
Well there you have it. Although I initially was thinking that my work would focus on business rules, it turns out that business processes will also play an important role in what I am doing. So I am educating myself (have been for a while now). Although my initial focus was to be on business rules, chances are you will see more on the topic of business processes, business process management, etc. in this blog the future.
I know. I am a few weeks behind but I figure that it is better to be late than never. I had to setup this blog before I could write anyway…
During the Business Rules Forum in October 2008, I attended a very interesting session that prompted me to start blogging and to seek out others who might have similar thoughts.
The session was called “One size doesn’t fit all” by two presenters from The Hartford. During this session they presented, among other things, a business rule categorization which contains the following categories:
- Front Ends
- Rating Engine
- Rules Engine
- Telephone Systems
- Relational Database
- Legacy Code
In essence, the identified that business rules could actually be broken down in different categories of business rules, reaching further than the traditional “Rule Engine” business rules which in this case is included in the “Rules Engine” category.
What caught my eye with this presentation is the uncanny resemblance to some work I had done in the fall of 2007. I had identified categories of business rules as well, some of which are very similar to the business rules categories they list in their presentation.
When I was working on my version of the categories, I thought I was the only one thinking about rules in that manner and had few people to discuss it with. Well now, it turns out that other people had very similar ideas!
After that presentation I knew I had to start writing. I knew I had to discuss the subject further with other people. I knew I had to start my own blog.
Chances are I will touch on this subject a lot more in the near future. This is what got me started in the first place after all. I’ll probably start by blogging on the subject first before putting it into a white paper. So if you are interested in this topic, keep an eye on future posts…
Well, it took me a while. I’ve been considering creating a blog for a while but never took the time and I wasn’t sure there would be any interest in what I have to say.
So this is it. After attending the Business Rules Forum in October 2008, I decided that it was time for me to actually do it. Why? Meeting with all those people, discussing business rules and seeing that some of my thoughts on the topic were not so far fetched or out of the blue after all.
I also wanted this to become a way for me to communicate with people who have similar interests. I hope that this will not be a one way street, but a place where people will also respond with their comments so that discussions can take place.
My position is that if someone does not agree with me there must be a reason for it, and maybe I can learn from that and adjust my views. In French, there is a saying that goes like this: “Seuls les fous ne changent pas d’idée” which loosely translates into “Only crazy people don’t change their mind“. So there you have it.