IIBA , you are wrong !! You need Business Rules Management!!
Published by Rajgo December 1st, 2006 in Business Rules, BRMS, Business Rules Management System, Business AgilityI have been going through the IIBA website, and have started reading the IIBA Body of Knowledge to understand more about Business Analysts.
Many organizations employ Business Analysts who act as a liaison between the business stakeholders and the IT. Business Analysts play a crucial role in organizations, and are typically at the center of the usual organization politics between IT & the Business.
Now, to summarize the BA Body of Knowledge, it essentially covers the following areas.
- Enterprise Analysis
- Requirements Planning and Management• Requirements Elicitation
- Requirements Communication
- Requirements Analysis and Documentation
- Solution Assessment and Validation
Now, I wanted to find out what is IIBA's take on how to manage business decisions and change. I must admit that I still have to read the whole document completely, but there was this section on business rules that felt me feeling very strange. Here are some excerpts, and my take on those.
Business Rules Management may be used whenever it is necessary to ensure that the policies that constrain and direct the operation of a business are well understood and correctly implemented.
Now, I am not sure how to understand this statement. Would it mean that you might have cases where it is not required that the business understand how decisions need to be taken. Now, come on !!
Business Rules Management, however, does require an additional set of documentation to be developed and maintained, and additional effort to ensure that the impact of the business rules on other functional requirements is properly understood.
Now, I would say that policies/rule requirements anyway would have to be written, and that would actually be one of the jobs of a Business Analyst.
Using a BRMS (Business Rules Management System), actually helps you implement your policies that your System can apply in a structured fashion that aligns with the Enterprise's idea of how the policies should be. I cannot see what the additional effort is going to be.
In many cases, using Business Rules will actually speed up your project.
This technique is most effective when business rules are applied across multiple processes, or when the solution includes a separate component for managing and enforcing the Business Rules.
If neither condition is met there is little value in separating the business rules from the other models used to describe the solution.
Now, now, I have this feeling that I am reading from a tech spec like the EJB or JDBC specs. I for one, feel that software is an enabler, and a General Purpose Technology. The Business should be driving the solutions rather than the other way around.
BRMS allows enterprises to clearly structure their policies in a fashion that can be shared between business & IT. It provides visibility into a running software system. BRMS allows business policies that drive automated Business Decisions to be managed like any other software asset. How much simpler can you get!
I am going to read the whole Body of Knowledge this weekend, and I should know more by Monday on this subject.
I wonder what how familiar the Business Analyst community is with Business Rules Management technologies. I would love to have some inside story there.



















Hi
I am interested to know what are your further thoughts on the BABoK. Didyou manage to go through the BABoK. Infact I have recently started reviewing the same and you can find some of my thoughts in my blog.
Thanks
When you finished reading the International Institute of Business Analyst (IBA) Body of Knowledge (BOK), did the statements in question fit the document where they were align?
The statements in question are listed under as an Appendix Technique: Data and Behavior Models .6 usage considerations. This is used to provide more information regard if the technique was used, some of the common considerations for the business analyst to take under advisement.
It does not appear that the IIBA BOK is stating that there might be projects where it is not required that the business understand how decisions need to be taken as you stated.
I would believe they are trying to give a collective thought for another business analyst to consider while mentoring that business analyst.
The IIBA BOK is still under review and the current version 1.6, may be download from the www.theiiba.org website, which contains more information. Here is a direct link http://www.theiiba.org/content.asp?contenttype=Body of Knowledge
Hi Rajgo,
The goal of the BABOK is to define the role of the business analyst across all project types and methodologies. That means that we have to find and articulate the common ground across all methods, not elevate one above the others.
While I understand that the Business Rules community is passionate about the architectural benefits of a separate BRMS, from my perspective business rules are just one more analyticial technique that doesn’t really change the way a BA works–there are quite a few other ways to capture how a business makes decisions.
I expect the coverage of business rules and motivation models to increase somewhat in future editions, but I have yet to be convinced that they represent a new way of thinking about requirements. As for implementation benefits and increased flexibility for the business–I’m personally all for that, but it’s not within the main scope of my concern.
However, I’m quite happy to hear from people in the business rules community about ways we could improve the BABOK, since I agree that we have a lot in common.
—-
Kevin Brennan, PMP
Vice-President, Body of Knowledge, IIBA
Thank you David and Kevin for participating in this discussion. I am still to complete reading the BABOK completely.
From a requirements gathering perspective, here is what I feel.
For the above cases, I do agree that requirements are not necessarily gathered using Business rule formats like Decision tables, trees or flow rules. But the emphasis here is on the fact that we have Business Rules down there.
Traditional programming techniques are not enough to capture the complexity of business rules. I have written about it here.
Talking about the benefits of a business rules approach, I would say that the benefits are not just architectural benefits. My list of benefits would read like this.
Hi,
Whilst all the points here are valid, a Business Analysts will generally rely on experience from themselves and other likeminded professionals to manage their organisation’s business rules due to the often delta like nature of organisational strategic focus.
I completely agree with the statement that Business Analysts often find themselves as the “center of the usual organization politics between IT & the Business.” As I have recently hung my title of consultant to delve back into the exciting world of business analysis.
In the last few years, I have not had the fortune to work for an organisation where the focus has been maintained on the goal to deliver the requirements that have been specified by the organisation. Which has made it increasingly difficult to track the business rules due to the shifting focus? It would be extremely nice to have a process that is capable of managing business decisions and change for organisations; however, over the last few years working as a business analyst, it has become more and more obvious that many areas of business do not understand their own organisations strategic direction which makes it difficult to deliver.
Regardless of the fact that requirements need to be managed by some methodology or process to ensure traceability, is it the job of the BABOK to specify a procedure to manage business rules that is generic enough to be used in multiple circumstances? Would it not be the place of the business analyst to utilise a process that they know will best suit the organisation?