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.
posted by Anonymous @ 12:47 PM
1 comments
1 Comments:
Process documentation should not be done in the form of business rules – as they live in different levels of abstraction and have different perspectives. A rule may be part of many a process, and have a different contextual relationship with each process.
Manage Rules and Processes separately as their perspectives at solving a problem in the business domain are very different. To bring them together, respecting perspectives, interleave Rules and Process at Decision Points, this will provide a clearer view, as you travel down the abstraction path.
We have to be mindful that business rules exist as a manifestation of variation in the economic market place. Key differentiators between processes that seem identical are the rules that live in their context.
As with any other collectible documenting exercise, collect artifacts, sort them by type, and weed out the semantic conflicts as you navigate the process. This is no different than what needs to happen in Business Rules space. Just because there is conflict we shouldn’t mix perspectives and end up with a knotted view of the business domain.
As you will see there are different levels of processes – some run the business – others manage the processes that run the business – for example like rules management and process management. There will be rules that live contextually in both areas.
An application is snap shot of a set of processes in time. This by itself is a difficult concept to digest – unfortunately – laying it in concrete – means the fundamental reason of mutability and agility is lost.
The above provides us the with a clue that IT has been driving down the wrong road – and we in the Rules/Process/Service space need to be wary of too close a contact with IT that is not loosely coupled and specifically defined.
Business Analysts should do both (Rules/Process) management – not either – and not necessarily the same person. Business Analysts need to manage their (Rules/Process) areas (perspectives) and as I have mentioned above – interleave – at decision points.
It is not an either or situation – it is about how they (Rules/Process) as first class citizens work together to enrich the business experience.
- SharpAlien
Post a Comment
<< Home