Last month I listened to a webinar hosted by the International Business Rules Forum. It was one of the few webinars before the forum starts on October 26 in Orlando. The BRF’s theme this year is "all around agility". This includes all topics around Business Rules Management, Business Process Management, Business Performance Management, Business Intelligence, Decision Management and other analytic activities.
In this webinar, Sandy Kemsley presented the combination of BRM and BPM and talked about true agility within this combination. This sounds very interesting to me, because my experience is that there is a strong relationship between business process and business rules definition and of course of the management of these assets.
So let’s have a look at what Sandy pointed out in her presentation.
First she defined the BPM discipline as
- a management discipline for improving cross-functional business processes (independent of the technology), and
- the methods and technologies tools used to manage and optimize business processes
Sandy talked about the goals behind all BPM initiatives. She said that the main goal in the last 8 years behind the most BPM activities is to become more efficient. This means increasing automation steps and handoffs and integration systems and data sources throughout all business processes.
After this is achieved, compliance is the next step: with the explicit representation of process definition you can show that you are compliant, because the business processes are now transparent and can be used for meeting new compliance requirements. Since 2005, agility and visibility have been the real important requirements inside the BPM activities. This means to be agile and visible brings the real benefit to organizations to reach their business goals.
This is exactly the reason why I see today a need to take a more in-depth look at the business rules inside the business processes, i.e., identify the business rules and describe this real corporate asset in a complete way: management information, business need, system relationship, rule statements, etc.
Sandy also defined BRM as a
- discipline for discovery and management of business rules, and a
- set of methodologies and tools to manage rules.
What she means is that there is a misunderstanding in many discussions inside the Business Rules context. BRM is much more than technology (or a rule engine). Like the name says, it is both a management discipline and a methodology.
This is what I also have seen in a lot of Business Rules projects: many IT professions see a benefit for their work, but the business department is often outside of those project activities. Often the discussions are tool-based. And often the methodology how to discover, describe, formalize and implement, and deploy business rules is the key factor to deliver successful business rules projects and implement the corresponding governance.
Does your company see that real agility is only reachable by separating BPM and BRM by extracting decisions from processes? Do you think using BPM on the one hand and using BRM on the other hand is enough? In my experience, you need an organization with an enterprise architecture skill to bring both parts seamless together.
What is your experience?
James Taylor said:
Thanks for the post. Yours was one of several that prompted me to write a post on why decision management matters to process management.
JT
James Taylor
Author, with Neil Raden, of Smart (Enough) Systems
Smart (enough) Systems LLC
Thanks for this Kai. I’d like to know more about the BRM methodology and how ARIS supports this. i.e. Discover - Describe - Formalise & Implement - Deploy. The ARIS rules designer site paints a good picture abt the product but there’s little info abt the steps taken to get to the objective - i.e improved visibility & agility. What I’m interested is the operational level details. In my experience, most of the management concepts sounds quite rosy on the strategic level, the actual challenge is in the operational level. Some more insight into this aspect would be very helpful. Thanks again for your article.
Thanks James for your comment on my blog. I met you on the last year’s BR forum in Orlando, where you introduce Nail Raden and your book Smart (Enough) Systems. The book describes very well the need and benefits of an enterprise decision management.
As you write in your blog http://smartenoughsystems.com/wp/2008/06/30/heres-why-to-use-decision-management-not-just-process-management/ is the combination of business rules management and business process management the door opener to do business driven decision management. This is also the first step to archive the full enterprise decision management benefits.
Good point Glanesh! This is exact the key point: what is the methodology to move forward from the strategic to the operational level and how does the product support this methodology. So let’s have a deeper look inside ARIS and how we build up the complete business rules lifecycle in a very short way:
First of all we identify inside the process models the hidden decisions behind a specific activity. Activities with more than one event’s are an indicator for such a hidden decision. This is one possible way to find decisions and to male those visible and transparent and changeable to the business responsible person.
In this discovery step we define a new ARIS object and a relationship to the function inside the process model. This business rules object describes on a very high level the business rule in his context. A new allocation diagram for this business rule object describe the responsibility on an organisational and person level and also describe the related technical terms as in- and outgoing business data. These diagrams are part be the description phase inside the business rules life cycle.
In the “formalising” or modelling phase we define the data model as a technical term, ERM or UML class diagram. This data model is base for the business vocabulary. The vocabulary defines all terms and facts as a part or the complete data model. If this definition is complete we define together with the business expert the business rules inside the ARID Business Rules Designer. We define if we split the rules in reusable rules and define a set of different rule sheets. We also define a flow a different rule sheets with a rule flow diagram. This is all about structuring rules and is the biggest and hardest part of the business rules life cycle. After the rules are tested and complete documented we set up all activities for deploying these rules to the operative environment. In this phase we talk about versioning of the rules and deploying the rules to the execution server as decision services. We also talk about which application server our customer use and need to set up all technical aspects.
Ok, this was a very short answer of the question how we archive visibility and agility on an operational level. I hope this gives you and the community a better understanding, what we understand under BRM in the ARIS context.
You also found some more details especially of the rule discovery process in my last post on this side. Please check the Business Rules category on the arisblog site.
Thanks Kai! That was very useful. It helps me understand the tasks and complexity involved in purusing the BRM path. Its my belief that capturing business rules is an important aspect to process modeling and it also acts as an explication of tacit process knowledge.
