Context sensitive Rule Management – Part 2

In my March 28th blog, I discussed process centric thinking and mapping business rules to process. As I stated earlier, business is a set of processes/services that it provides to its consumers. Business rules define how each process functions and how processes taken together allow a business to function. Let’s take an example of e-Commerce web site which takes orders from customers and fulfills customer’s orders. In this case, one process for this organization is, “Order fulfillment”. At the highest level it can be defined as
Gather customer information
Gather items that customer ordered
Take method of payment
Place a block or authorization on payment
Check the stock to fulfill the items that customer ordered
Place them in one or more boxes
Ship them to customer
Upon customer receipt, charge him.

Each step may itself explode into complex multiple sub steps or processes. So depending on organization size and number of processes; interactions between them may be very complex to define. When enterprise wide initiatives are made, even at the process level, people quickly get confused in communications primarily because they lack a common enterprise-wide vocabulary. The solution is to get control over what business can be defining by:

1) Creating common enterprise wide vocabulary thru which every one can communicate. (No interpreted meanings. Clear definitions)
2) Creating processes by using the vocabulary defined above to the granularity desired
3) Creating teams to define a process or sub process with an understanding of its functionality in end to end process definition.
4) Defining Requirements using common vocabulary (Enterprise repository) and creating any additional vocabulary before using it in Requirements

Strictly following the above rules automatically applies the concepts of “Contract first”, “SOA”, “Integration from day 1”, and handful unambiguous documents.

View the original article here

Context sensitive Rule Management

In my 15 years of IT experience, I have visited quite a few companies. Every company attempted, to some degree, to document business process in the form of rules. At the beginning, everyone is over enthusiastic and starts writing every detail as a business rule. At this stage, when a new rule is added, majority of BA's will not look into whether new rule would contradict with existing rules. This is starting point for contradictory / conflicting rules documents. Worst of all, at the corporate level, these initiatives happen in parallel and each department starts documenting rules whenever something comes to mind. IT builds applications based on a set of business rules which develop themselves into a concrete process with an input and output. An individual business rule is always a statement or a fact in the process, but can never be a process by itself. IT builds an application for a set of business rules which are cohesive in nature and accomplish a goal. This means that BAs should start from business PROCESS, not from RULES. After all, a business is a set of well defined processes/services to its consumers. Addressing rules from a process-centric viewpoint gives rules a context. Then BAs can ask themselves questions such as “How many processes are defined?”, “What portion of a process is defined?” Definition of a process can be expressed in business rules. Process-centric thinking while defining business rules has lots of advantages. It brings lots of new perspectives into the picture. In my next blog, I will take an example and explain how this process-centric thinking helps bring context to business rules. I will also explain the benefits BAs would gain by adopting this process-centric thinking.

View the original article here