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.