Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Requirements  Business Policy vs Business Rule
Previous Previous
 
Next Next
New Post 7/8/2012 1:22 PM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Business Policy vs Business Rule 

David:

Further clarification:  by Data Dictionary, I mean a Logical data dictionary.    Logical data dictionaries are totally, 100% implementation independent.   Now, there are other data dictionaries that are implementation (e.g., database) oriented, but those are developer artifiacts - not business analysis artifacts.  These other dictionaries are often called Physical data dictionaries.

The way things are supporsed to work is that the BA creates a business oriented logical data dictionary, and then the developer using such as an input to creating the physical data dictionary.   But, often, projects just focus on an implementation oriented dictionary.

Tony

 

 

 

 
New Post 7/9/2012 5:22 AM
User is offline David Wright
141 posts
www.iag.biz
7th Level Poster




Re: Business Policy vs Business Rule 

 Well, time to clarify terms. When I say "system", I mean an information system. I would still like to hear your views on business rule methods.


David Wright
 
New Post 7/9/2012 7:27 AM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Business Policy vs Business Rule 

David:

Information system sounds "computery" to me.    A  bunch of people working at a company, with only pencils and paper - zero, nada one computer, can be an information system.  

Regarding the term "system", the whole BA career field runs on false partitioning (i.e., false division of tasks and terminology).    Exmaple, per the BABOK: data flow diagrams are for analysis of system requirements and business process modeling is for analysis of business requirements.   Totally popular, totally twisted.   This is tragic as, analysis, especially analysis of business systems,  IS largely all about effective partitioning (decomposition).  

Regarding business rules, they are system  behavior to a more detailed level.   Once a complex business system (manual/automated, or a combo thereof) is properly decomposed to smallish, equal size pieces of minimum coupling and maximum cohesion, then business rule discovery  can commence per piece (i.e., process/task/function).    How business rule documentation occures,can vary.    The main point is for a BA to not make the mistake of starting with a bottom up approach on a complex business system, as such approaches, by their nature derail effective decomposition.

Tony

Tony

 

 
New Post 7/9/2012 10:18 AM
User is offline David Wright
141 posts
www.iag.biz
7th Level Poster




Re: Business Policy vs Business Rule 

 low coupling, high cohesion... takes me back 30 years... still a good basis for an information system design architecture.

So, what about rules that impact multiple pieces? Do you define them multiple times, or define them once outside the piece and cross-reference each rule to all the pieces? Certainly the second way makes for less volume and much easier impact analysis when rules change, because rules change a lot in response to what is happening in or to the business.

What about new rules that come from outside the business? like new laws and regulations? how do you determine the pieces that are impacted?


David Wright
 
New Post 7/9/2012 1:33 PM
User is offline Tony Markos
493 posts
5th Level Poster


Re: Business Policy vs Business Rule 

AAAaaaahhhh..... impact across multiple [system] pieces.  This (along with ..... tremble..... decomposition) is a forbidden topic amongst BA's!

Proper handling of rules across pieces [of the system] is through proper partitioning, through as many levels of abstraction as needed, to minimize data flow between the pieces.  With a farily common five levels of decomposition for a business system (I have often gone alot deeper than this), there simply is no other way to reach the final goal of smallish, loosley coupled, cohesive approx equal size pieces, needed to really address the issue.

When there are still impact between pieces issues, then any of your alternatives could come into play.   And there will always be such issues.  But, a genuine effort to first logically partition/decompose will result in a much better result than the typically force fit attempts at business rule intergration.

New laws and new regulations require new processes (with interfaces to existing processes) to handle them.   So the scope of the info system expands.   What would I do?   Create a new Context Diagram, then decompose it downward with data flow diagrams until I have the right pieces again.

Tony

 

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Requirements  Business Policy vs Business Rule

Community Blog - Latest Posts

Today I had the pleasure of chatting to Jignesh Jamnadas, Chief Operations Officer at Mosaic, about his Blueprints for Success. As a Senior Finance and Operations Executive, Jigs (as he is known to many) has a holistic understanding of all facets of business and a flair for managing both people and processes. Having worked with Jigs, I was struc...
I recently had the pleasure of chatting with Wolfgang Goebl, a visionary in the field of business architecture and enterprise design. His unique approach, which he refers to as "architectural thinking," and his work with the EDGY framework, offer valuable insights into the future of organizational structure and design. This tool covers th...
Our next speaker in our Blueprints for Success series is none other than Roger Burlton, a prominent leader in business architecture. As founder of Process Renewal Group, Roger has spent over three decades helping businesses worldwide translate strategy into execution. “Intention is everything.” – Roger Burlton Known for his ...

 






 

Copyright 2006-2024 by Modern Analyst Media LLC