This paper is written to provide a better understanding of the business rule approach and to overlook the impact and the role of that approach on the different aspects of the business including the business process re design and process improvement.
The whole paper will discuss the applicability of the business rule approach under the heading of grouping of business rule and to discuss the motivating factors against grouping of these rules. The different areas where these rules can be effective along with the barriers in the approach.
The heart of a business rules approach is an approval for rules as a precious advantage for a business organization. In fact, a business rules approach to systems development elevates the importance of business rules to the business and carries that importance into the organization's systems development function and approach.
In some cases, organizations are truly leveraging the business rules approach by incorporating it into business process engineering or re engineering initiatives. To these organizations, a business rules approach is an avenue through which to drive change across large business scopes.
Business rules are a formal expression of knowledge or preference, a guidance system for steering behavior (a transaction) in a desired direction. On the grand scale, business rules, then, are the guidance system that influences the united behavior of an
Organization's people and information systems.
2. Introduction
Business rules are the abstraction of the policies and the practices of the business organization. The business rules approach is a development methodology where rules are in a form that is used by, but not fixed in Business Process Management Systems.
Business rules guides your business in running day to day operations. Without business rules, you would always have to make decisions on the fly, choosing between alternations on a case by case, ad hoc basis. Doing things that way would be very slow. It would likely produce widely inconsistent results. In today's world we cannot really operate that way -not for very long, anyway. So every organized business process has business rules.
Business rules are not Software: Business rules are often implemented in software but that is a different matter. In fact, application software is only one of several choices that consider, alternatively implementation approaches include supporting them in manual procedures the point is that business rules arise as an element of the business, as the name business rules suggests not from any particular hardware software platform.
Business rules are not process: Roger T. Burlton (2001) recently expressed the business rules message this way “separate the know from the flow” the implication is that the “Know” part and the “flow” part are different business rules represent the know part- the separate stuff that guides the flow. Guidance's means rules hence the name business rules.
“Separate the know from the flow”
- Roger T. Burlton (2001)
The Business Rules Approach formalizes an enterprise's critical business rules in a language the manager and technologist understand. Business rules create a clear statement of what a business does with information to decide a proposal. The formal specifications become information for process and rules engines to run.
A business rules approach aims to deliver that guidance system as externalized rules, automated as an integral and active component in systems architecture. There in lies the new emphasis: a knowledge-focused way of designing new systems. It is no longer acceptable to bury that knowledge deep in code where no one knows what it is. It is equally no longer acceptable to have that knowledge locked in bondage where it cannot change on demand.
3. Business Rules Modeling
In the recent years there has been an increasing interest of the IS community in the business rules, which has resulted in dedicated rule-centric modeling frameworks and methodologies. The term “business rules” has been used by different methodologists in different ways:
For example as defined by Ronald G. Ross (1994).
Business rules are “A discrete operational business policy or practice. Businesses rules may be considered a user requirement that is expressed in non-procedural and non-technical form (usually textual statements) a business rules represent a statement about business behaviors”
By D.Rosca et-al (1997).
Business rules are “statements of goals, policies, or constraints on an enterprise way of doing business”.
By H.Herbst (1997) business rules are “Statements about how the business is done, i.e. about guidelines and restrictions with respect to states and processes in an organization”
Krammer considers them as “programmatic implementations of the policies and practices of a business organization”
Finally Malcolm Chisholm (2001) briefly explains the business rules are the single statement that takes data or information that an organization processes and derives other data or information from it, or uses it to trigger an action
Business Rules Oriented Conceptual Modeling (BROCOM) provides meta models that formalize business rules in conceptual modeling. In BROCOM, a business rule is composed of three components namely Event (E) that triggers business rules, Condition(C) that should be satisfied before action, and Action (A) that describes the task to be done.
Thus the Business Rules are specified in ECA structure. In addition, BROCOM provides a meta model that links business rules with organizational facts such as origin, processor, and organizational unit as its components.
Figure: W. M. N. Wankadir and Pericles Locopoulos (2003)
4. Basic principles for business rules approach:
(Ronald Ross G. 2003)
An approach for partitioning business rule base was taken by Brown and Pomy Kalski (1995). Where a rule base is partitioned into set of chains (the horizontal partition) and a set of groups (vertical partitions).
Organization Rules Vs Grouping Rules:
It is pertinent to differentiate business rules taxonomy from business rules grouping. While organization classifies business rules into certain fundamental types, grouping is done based on interrelationship and interface between rules.
A group when sets up a project, decides to execute the same on the basis of some rules which are formulated for the efficient execution of the project. The rules are set up in a definite hierarchy and implemented in a definite hierarchy and implemented in a sequential mode of formulation.
Rules are formulated under stringent guidelines which may be either Laws or Theorems. They are not individual sets and cannot be implemented solely but they do work in perfect coordination with other sets. This relationship could be as simple as mere references or as complex as casualty. In case of change in one rule the other rules are also affected.If the rules are not organized the impact of the change in Business Model on business rules can't be traced, redundant rules will be created, rules cannot be processed efficiently, and the decision making with these rules will not be expedient and new rules will not be identified.
The business rules can be grouped in six major types based on rules reference to: (i) definitions, (ii) objects, (iii) facts; and rules arranged along (iv) criteria, assumption and operations, (v) business policies and (vi) logical relationship, such as, prerequisite, interference drawing and Impact.
1 .Grouping For Efficiency of Processing
These groupings can help design and organize business rule bases to increase the efficiency of processing rules and help track changes in the rules when business model or business process under goes change and vice versa. In the following section these groupings have been discussed in some detail.
Rules refer to other rules at the time of their execution. This happens particularly when business rules refer to definitions which themselves are expressed as rules. Every business domain has some terms that carry specific meaning in the domain and represent some aspect of domain knowledge. These terms are called business terms, which capture and represent some aspect of business. They are expressed in from of the rules, which may be referred to as definition rules.
An example of a rule referring to a definition
Rule 1 If the customer is a ‘Privileged Customer' THEN the customer may exceed his credit limit by 20%.
Some Important Observations on Rules referring To Definitions:
Grouping rules for ease of decision making involves separation of concerns. Decision making concerns are separated from programming details. It doesn't mean, though that these concerns have nothing to do with each other. It only means it concern different people with different functions to perform. Business decision making concerns the manager while programming details are something a programmer is to take care of. The whole discussion above has looked at the business rules interaction s and forming business rules grouping based on them, with twin purpose of efficiency of processing business rules and ease of decision making.
Business Process Redesign:
Business process redesigns “the analysis and design of workflows and processes within and between organizations” (Davenport & Short 1990).
Teng et al. (1994) define BPR as “the critical analysis and radical redesign of existing business processes to achieve break through improvements in performance measures”
After having a through understanding of Business Rule Approach the question arises where do these rules apply or how can this approach be helpful in business process management. Many organizations need more than incremental change in existing process to achieve the necessary outcomes, they don't need to make existing processes more efficient or effective, and they need to identify fundamentally new ways to do business. Some analysts believe the combination of business rules technology with Business Process Management offers an agile approach to work flow and enterprise integration. BRM and BR soft wares support business goals by managing and running business processes and business rules separately yet complimentary ways. A Business Process is often a complex map of work flow controls. It might have sub processes, decisions and while loops. Wherever a decision or while loop appears, business rules can evaluate the date provided by the process and controls the basis for change in flows. Business rules approach and its effects in business process re design and process improvement can be discussed under the following headings.
1. Re Engineering's: The first category to which Business Rules Approach (BRA) involves projects to re engineer business processes. The focus here is a top down, business driven requirements process. Business Rules Development especially for core business rules is a critical part of such an approach for at least two reasons.
Business rules play a central role in strategizing that is in rethinking the business problem and developing a full and optimal business solution up front.
Business rules sharpen and compliment other, more traditional deliverables (for example workflow models). In short business rules handle the business logic portion of re development efforts.
2. Re Deployment:
Just about every company these days is eying the web as an environment for redeploying basic business services. To do that, a company must identify and encode the business logic that governs those services (that is the business rules).
This type of project actually represents the larger problem of how to exploit new hardware/software environments more quickly and cheaply. In other words, how to re architecture the technical environment. By no means is this problem limited to organizations that have been around for a good while. For example a company looking with dot.com who is looking for a way to escape their unlivable five years old legacy hardware/software environment. Legacy time frames are continuously shrinking, so the business must find new ways to become ever more nimble about migrating business logic from one environment to another and that is only possible if the company applies those business rules approach for re designing and improving the current old business processes.
3. Recapture:
There are actually several related “Re's” in this category- reverse re engineering, retention, and re documentation. This type of project is really motivated by fear (or risk avoidance, to put a more positive spin on it). The issue is how to avoid losing your business rules. Many business rules, for example, are buried deep in undocumented legacy systems. Here the focus is on reverse engineering of the program code to get at the business rules-that is, on rule mining.
Other projects focus more on knowledge retention: identifying those workers who know business practices, sitting them down in a room together, and extracting the rules on facilitated basis. The objective is to record these rules before the workers are lost or retire-or to the competition.
Whichever way you chose to recapture the rules (whether by rule mining or by understanding facilitated retention sessions), the objective is to re document your business rules.
4. Re empowerment:
This is perhaps the most exciting area of business rule activity in process design. Initially, these categories focus on customer relationship management (CRM). (This focus is currently expanding). Companies are using business rules approach to handle highly individualized customer relationships on a huge scale.
For that companies must do three things.
You must record and manage the rules on engagement. (Many companies are so out of touch with their customers you could probably call this an attempt at re engagement.)
You must operationally new or modified rules of engagement quickly-weeks or months of delay in programming are unacceptable.
You must manage the rules of engagement on business side, not the IT side. In other words you must re empower business users to manage the rules directly.
Advantages of Business Process Redesign using Business Rules:
A business rules approach organizes the technology and supervises the decision making capability of an organization and develop urge of using that technology as an additional rule. These business rules approach emphasis on business rules instead of system's requirements. Good analysts understand the business designed for a system. These analysts gather user's requirements for the system and these ‘system's requirements' are really mean to gather ‘business rules'. So it's not a new approach, business rules are something which always implement to describe an excellent and accurate way to analyze a system.
Taking the business rules approach offers three unique benefits:
The rule track: Integration of object-orientation, information engineering, and rule formalism Correlation of rules to business motivation (strategy, objectives, goals, tactics) the most unique aspect of a business rules approach is the introduction of a rule track. It represents the set of rules behind the interactions and over the data, where the rules are managed as a separate, externalized, logical component.
You can choose business rules technology that is designed specifically to manage the execution of a rule collection. Alternately, you can utilize no business rules technology, even homegrown Java, but in a way that leverages the concepts and advantages of a business rules system.
The second unique characteristic of a business rules approach is that it represents the integration of object-orientation, information engineering, and rule formalisms.
The third unique characteristic of a business rules approach is that it correlates the underlying rules to many aspects of business motivation. These include goals, objectives, strategy, and tactics. In this way, the business can evaluate the effectiveness of the rules in guiding the business toward its desired ends.
The pressures facing many businesses today can seem insurmountable. Most of these pressures require changes in the way the business operates through its underlying automated systems. Even more challenging is the realization that customers, competitors, or legislative requirements impose many of these pressures. The following nine common scenarios in today's business world can be improved by applying a business rules approach.
The business needs to change, but its systems are barriers to change. Most of today's operating systems are similar to black boxes because there is a lack of documentation and knowledge about them. Without proper documentation and knowledge, the task of upgrading the systems is time-consuming and costly at best, and impossible at worst. The lack of knowledge of internal and buried system logic became apparent in the costs of the Y2K projects.
New legislative mandates and directions are underway that not only require adherence, but also open the doors to new business opportunities. Adherence to new legislative mandates usually requires changes to existing systems. New business opportunities may require changes to existing systems or the building of new systems. In pharmaceutical research, for example, some changes involve reducing clinical trial times for treatment possibilities for life-threatening diseases.
Business process re engineering continues. Some of these efforts sometimes aim to create a consistent global perspective for a given process. Or a BPR effort can aim for a customer-centric process. Regardless, these efforts take a top-down view to streamline a business, make it more effective and smarter. BPR initiatives often change culture and strive for consistent or at least visible policies and rules across organizational barriers.
The application backlog is unending. There is an increasing desire for e-business applications. IT functions need to develop new systems and change existing ones faster than ever before.
Many simple and valuable ideas are met with resistance. While there are many reasons for resistance even to good ideas, the two major barriers are cultural discomfort and profit motive, that is, cultural discomfort and price-driven resistance.
Cultural discomfort arises because an organization is accustomed to developing systems according to in-house traditions (or lack thereof) and the pride that accompanies current practices. The idea of changing those traditions, even for a better way, may seem, at first, like an admission of failure. It is sometimes difficult to perceive the fine-tuning of an already successful approach as a sign of leadership.
As a comparison, it may be interesting to contemplate the original resistance to relational technology. When relational products emerged on the marketplace, some visible industry commentators proclaimed that the relational model could not work at all, or could not work well. As a small admission, some resistors hesitantly accepted that perhaps relational technology was appropriate for query systems, but that it certainly was inappropriate for transactional systems. Many people found it difficult to accept the fact that a DBMS optimizer could select a valid access path and perhaps do so better than an experienced programmer. Other people could not imagine a DBMS that did not rely on visible intra record pointers because these people could not conceive that a DBMS without such visible pointers could ever perform acceptably. Most of these resistances were either untrue or have been overcome.
Profit-driven resistance is interesting because today's business world is accustomed to reducing all ideas to profit potential. Without very short-term profit realization, good ideas and approaches are slow to gain acceptance. The fast-paced world wants to see profit benefits well predicted and immediate, if possible.
The good news about a business rules approach is that it overcomes both kinds of resistances. From a cultural perspective, there is no doubt that most current systems development practices are seriously lacking in effective management and automation of business rules. Therefore, regardless of an organization's favorite systems development approach, it is lacking in this regard, but so is everyone else. There need not be a sense of personal or organizational failure. It is simply a maturation process
No doubt today businesses face change and uncertainty. There are rules-technology products delivering on the promises of the business rules approach. There are a growing number of positive and successful customer experiences. As a corollary, the business rules approach makes its initial successful entrance because it satisfies the business's need to work with systems that can change easily, especially where the business leaders themselves more directly guide those changes. A business rules approach begins with the language of the business people and traces those requirements to an implementation that allows for easy changes. This is a niche that is badly needed now. Over time, a business rules approach will become the standard way of developing almost all systems.
While concluding the whole discjhi2ueussion on the business rule approach we can say that a business rules approach is a methodology—and possibly special technology -by which you capture, challenge, publish, automate, and change rules from a strategic business perspective. The result is a business rules system, an, automated system in which the rules are separated, logically and perhaps physically, from other aspects of the system and shared across data stores, user interfaces, and perhaps applications. Finally the above discussion it can easily assumed that business rules approach is very helpful and provides a systematic approach to the systems.\
Available At:
http://www.sciencedirect.com/science?_ob=ArticleListURL&_method=list&_ArticleListID=499241711&_sort=d&view=c&_acct=C000050221&_version=1&_urlVersion=0&_userid=10&md5=c32f76333cc400dc971f81f3acdd123b
[Accessed 25/11/06]
Available At: http://www.tdan.com/i019ht03.htm [Accessed 30/11/06]
