BEST PRACTICE

The term ’best practice’ is a simple concept. I am at point A and I want to get to point B. How should I go about it? I brainstorm some options. Have I done something like this before? Has somebody else done this before or something similar to it and what were the results? What resources are available to me? How quickly do I need to achieve my goal, what do I need to be prepared for at point B, what are the consequences of my actions? I make a decision based on my goals, values, and strengths. If part way there I learn something new, I make adjustments. If many have gone from point A to point B before me, I have a broader base of experience than my own to draw from. The other experiences are not likely to match my own exactly, but I will assess them to see if they are applicable -provided I have the information to do so. If others who have experienced this situation first hand have found some common ground or best practices, this is even more valuable. I have best practices and examples of these practices to reinforce my understanding and guide me.

In the context of business rules, what is currently available to help us navigate from point A to B, or even from A to Z? Our knowledge is much more fragmented than in general software development practices. On one end of the spectrum, we have a significant body of knowledge on defining and modeling business rules, independent of a technology implementation. On the other end, we have the low level details for using a business rules engine. The problem is the knowledge gap in-between. While we see examples of businesses that have achieved success, we don’t have a body of best practices yet to guide us. We need to make more connections from one end of the spectrum to the other. If the gap persists, we will not achieve the true value of business rules.

We need to work in both directions, from business to implementation and from implementation to business. From the implementation end, we will not realize business change by simply extracting rules out of code and putting them in a rules engine. We need to help our organizations identify and understand the opportunities made possible by business rules. We then need to organize and implement our rules in such a way that we can achieve the business objectives.

As a business we may be looking to implement business rules because we value consistent application of business practices, managed complexity, retained and accessible knowledge, and quick response to business change. But more specifically where are we today and where do we want to be?

Business X, for example, is feeling pain because it currently takes six months to implement and rollout a moderate-sized change. This type of change is not uncommon to the business – it is a regulated industry and there is a regular cycle of change. If the business values quick response to business change, how quick is quick? What type of change occurs and how often? What are the change points? Who has the knowledge to make these changes? Who should implement the change and what type of change control process is needed? How do we test the change? Do we need to support versioning so multiple rule versions can co-exist? What types of rules do we want to be able to change without having to modify the application itself? There are lots of questions and opportunities for best practices to guide us.

Take for example pivot points- the attributes around which our business changes. In insurance, there are different rules for different states, so states are a pivot point. If you include this pivot point in the rules, you will be changing the rules often. Just because rules can be changed, doesn’t make it a good practice. A better practice is to use attributes on rules to handle change points. Changing attributes on relevant rules is simpler and more expedient than changing the rules.

What does all this mean? Good design practices still apply to business rules. We need to make the connections from the business goals through to implementation. We need to look to existing design practices for guidance, assess how business rules need to change or enhance these practices and be rigorous about their use.

View the original article here