Column 2« BlogNotes on my blogroll | Main | Mashups and the corporate SOA »
January 25, 2006Business (rule) analysis
I received the call for papers for the 9th International Business Rules Forum, which has prompted me to browse through the other business rule-related tidbits that I've been viewing over the past few weeks. If you've been reading Column 2 for a while, you already know that I think that business rules are a crucial feature in BPM, whether the BPM contains them inherently or as an add-on: you can find some of my previous posts on BPM and business rules here, here, here and here.
Rolando Hernandez recently posted a short term outlook for business rules -- in short, that BR provide huge competitive advantage through business agility -- plus an opinion on the differences between a business analyst and a business rules analyst.
The business rules analyst is focused on separating rules from code. The rule analyst walks and talks business... The rule analyst talks about business rules and business logic. The rule analyst means business.The business analyst sees rules as code. The business analyst talks about the system. A business analyst is often a systems analyst by nature, and by training... The systems analyst means code.
I don't think that there is a big difference in the inherent skills of business analysts and business rules analysts; rather, I think that systems analysts need to stop foisting themselves off as business analysts. Rolando starts a paragraph describing the business analyst ("the business analyst sees rules as code"), segues through an assumption ("a business analyst is often a systems analyst by nature, and by training") and by the end of the paragraph is referring to the systems analyst rather than the business analyst, as if there were no difference. Yes, this happens, but it's unfair to paint all business analysts with the same brush.
I also see the opposite problem, where a business user is designated as a business analyst, even though he (or she) has no skills or training in analysis; since he's not trained to write requirements that are both necessary and sufficient, the resulting solution will not do what the business needs it to do. Furthermore, since he's probably not up on the latest in associated technology areas, he's unlikely to think outside the box because he doesn't even know that the box exists.
The trick is to meet somewhere in the middle: a business analyst or business rules analyst needs to be focussed on the business, but be aware of the capabilities and limitations of the technology. The first job of the business (rule) analyst is to determine the business requirements, not write a functional specification for how the system might behave, as I've posted in the past. A business analyst needs training in the business area under study, but also needs training and experience in gathering requirements, analyzing business functions, optimizing business processes and documenting requirements, plus a high-level understanding of the functionality (not the technology) of any systems that might be brought to bear on a solution.
Posted by Sandy Kemsley at 08:52 PM in
BRE
• SoftwareDesign
| 
Digg This | 
Add to del.icio.us
Trackback Pings
TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/26
I have reached your colum 2 and read the definition of / opinion on "Business Rule Analyst (BRA)".
I felt that the new phrase BRA is unnecessary. Soon enough, I found your reasoned comments. They are very appropriate and helpful.
Essentially, "Requirements Analyst (RA)" together with a "Domain Specialist (DA)" specify how a user would interact with the system (to be developed) to serve a business function. Surely, business rules and business logic have to be precisely formulated in a manner intelligible to users, analysts and developers. To me it appears that a "Business Analyst" combines the knowledge and skills (K & S) of RA and DS. I am working on a methodology and tools to impart such K & S.
Posted by: Putcha V. Narasimham at January 27, 2006 02:30 AM
