Business rules as a distinct focus of interest in the system development life cycle had humble beginnings. In the 1980's business rules became a subject of discussion in the data management community. To many at that time and in that context the phrase “business rules” simply meant the referential integrity rules to be applied to data. It soon expanded to the broader context of rules about what were valid states of data, such as "All Preferred Customers must have an Account Balance of at least $100,000." In fact some rule software takes this “data centric” approach to defining and managing rules today.
As these technologies have matured along with those originating out of artificial intelligence roots, and as the demand for system agility has continued to grow, business rules have begun to assume a more prominent role in systems architecture and systems development. The basic idea is that business rules should be implemented so as to make them readily accessible and independently changeable as needed, in a context that is as business friendly as possible, not in system speak. Interesting issues of governance, consistency and traceability start to surface when embarking on this path but the fundamental concept is a compelling one.
Where then, when you’re designing a system or even conceiving system architectures, do you begin thinking about business rules? Fairly neat and satisfying arguments have been made for independent treatment of business rules throughout the life cycle, from early visioning through development. For the purposes of this article, though, let’s eschew theory and look at what practice in the field has shown to be workable. What is offered here is not an exhaustive survey, but does represent personal experience from a reasonable breadth of exposure.
Possibly the most common perspective today among systems practitioners is that attention to rules comes at the end of business analysis, as you move into design and development.
To some degree, this viewpoint reflects traditional practice. Business analysts are most familiar with process modeling of one form another. For them and for many business stakeholders as well, this is the most natural way to visualize and communicate about what the business "is." Thus business rules can be viewed as simply an adjunct or further detailing of process specifications.
Over the past several years, we have been involved in a number of projects where business rules were being specified as independent artifacts. By that we mean that the business rules were not simply embedded in process descriptions, but captured in independent work products and organized into sets that were then related to process. These projects looked at real world business problems while also examining how best to integrate business rules specification into the life cycle. A major objective has been to improve the clarity and completeness of delivered business specifications through formal treatment of business rules, but to do so as efficiently as possible, without adding prohibitive cost and time.
Iteration between process and rules proved most effective. A full description of the approach is beyond the scope of this article, but the somewhat simplified essence was this: whenever a decision point – evaluation, computation, etc. – was encountered at any level a switch was made from process to a "declarative" approach. That is, we asked "What factors are involved in making this decision? What else do I need to know in order to make this determination?" without regard to the mechanical process flow involved. In addition we asked "Why do I need to know this?” to help determine whether the question being asked was just a component of a larger decision that was currently buried in the process flow. Asking this question also helps affirm or drive out the business motivation behind any rule set so that traceability can be maintained and the impact of future changes in that business motivation can be rapidly assessed.
By actual test, this approach produced simpler, clearer process models, and uncovered rules that more closely reflected the real rules of the business, as opposed to procedural "rules" associated with the details of a particular current state process implementation. As a result, these models also reflected a cleaner separation between the business model and design, clearly defining the former while minimally constraining the latter. In one real life example, a strictly hierarchical approach to process modeling was applied initially, with business rules placed at the bottom of the hierarchy and specified last. Qualitatively, the models were found to be overcomplicated and hard to navigate and understand. As a test, the more iterative approach was applied to these same models, after the fact, with business rule sets integrated wherever appropriate in the business process model. The result was an over a 50% reduction in the number of components while increasing clarity from both a business and designer perspective.
Our conclusion was that business rule and process analysis are best pursued in an integrated, iterative fashion, with one informing the other.
Another common view is that a business rules focus and business rule methods are only relevant when you’re deploying rule engine technology. Our experience, as covered above, was that creating explicit business rules work products and integrating their specification with process analysis produced clearer and more complete business models irrespective of the technology being deployed.
In areas where rules play predominant roles, such as customer profiling, or product/service eligibility and configuration, taking a more data and rule oriented perspective very early in the life cycle has proven quite effective. This involves looking directly at key entities such as customers, products and services, the states they may be in and the rules associated with qualifying them for and transitioning them among those states. This approach helps partition and attack the complexity involved, and in such situations can be most natural for the business as well. From the identified states and rules, the essential process flow can be derived. In such rule intensive business areas, some organizations have even started with a survey of existing systems from a rule perspective, as an effective tool for identifying areas of overlap and for evaluating opportunity and difficulty based on an assessment of rule complexity and volume. In some projects, issues of rule consistency and underlying policy have acted as the fundamental business drivers, and were addressed first.
Our conclusion from all this is that business rules play a role early in business modeling, integrated with process modeling and in some cases as a key factor in system scoping and even architecture analysis. Doing so will help organizations define and establish a business model tuned for agility and service oriented architectures. We'll leave it to you to connect the dots on that one, at least for the moment.
Art Moore is a business architect with over 24 years experience in the field. A major focus for him in recent years has been in assisting major commercial and government organization to incorporate improvements in business rule methods and management. He is a contributing author of Business Rules Applied (principle author Barbara von Halle). He can be reached at art_moore@msn.com
There are no products in your shopping cart.
| 0 Items |
Membership at BPMInstitute.org includes access to our other communities
