Chapter 4. Business Rules

Business rules enable businesspeople to express requirements regarding what is required without needing to define the details of where and how the requirements are enforced in the operation of the business. Effective specification and management of business rules can ensure consistency in operating practices and compliance with regulatory requirements. The ability to change and quickly deploy business rules can have a significant impact on enterprise agility.

The value of rules in automated business systems is that they enable a businessperson to understand and express a requirement, based on understanding the business implications but without the need to understand the technology that applies it. Rules can also support complex decision making where all possible results are not explicitly programmed. For example, rules can be used to configure a product without explicitly defining all possible configurations, or rules might be used to load a truck with packages of different sizes and shapes. So rules can be used to enforce a spectrum of requirements, from configuring complex products to discovering a design defect. Rules are an important form of expressing knowledge and control.

There are significant differences between the various types of rules that may be called business rules. It is important that the types of rules be understood because the contexts of application, the forms of the rules, and the mechanisms of implementation vary. Based on consideration of the various types of rules, we consider the implications of SOA.

Types of Rules

The term business rule has a variety of interpretations, depending on the context of discussion and the background of the participant. In general, a rule is a statement of truth of a relationship of two or more facts. So we might say “A customer must have an account number,” or “A valid purchase order must have the signature of a person with appropriate authority.” Or we might define an action to be taken when a condition is true: “If a customer does not have an account number, then one must be assigned.”

Some rules may be incorporated in automated business processes or computer applications, and some rules must be applied to the behavior of humans. Where possible we should look for ways to manage and implement rules in automated processes and applications to ensure consistent application and improve control and flexibility.

The following subsections describe seven types of business rules: regulations, enterprise rules, production rules, diagnostic rules, event rules, qualification rules, and data integrity rules.

Regulations

Government regulations are effectively rules that define the bounds of legal behavior. Most regulations are expressed in a natural language (e.g., English), a form that requires some interpretation. In some cases regulations are intentionally vague to accommodate special interests or political pressures or to allow for a range of circumstances.

Regulations must be interpreted in the context of a particular enterprise, and the approach to application of the regulation may reflect consideration of risks of violation such as the likelihood of accidents, oversights, or mistakes, as well as the potential consequences to the enterprise and individual employees.

Some regulations are quite abstract, expressing an objective rather than a clear restriction on operations. The Sarbanes-Oxley Act, for example, requires accountability and control. Executives must ensure accurate corporate reporting. This requires measures such as separation of duties, disclosure of conflicts of interest, restrictions on spending authority, and independent review of operations. These measures are pervasive and must be addressed in the design of enterprise processes.

On the other hand, some regulations can be very specific. Tariffs, for example, define the rates to be charged for specific types of service. Taxes are usually very specific as well. Similarly, hazardous materials regulations can be very specific about precautions and prohibitions regarding use, storage, and transportation. It may be relatively straightforward to implement such regulations. But some regulations, such as the Corporate Average Fuel Economy (CAFE) regulations, are very specific but cannot be controlled directly since the target average depends on production schedules that are driven by market demand.

Most regulations are not published in a form that can be used directly by automated systems. There must be some transformation by humans to codify the required intent and identify where, if possible, the controls can be implemented in business processes or computations.

In the future, regulations may be codified so that they can be interpreted and analyzed by computers. The Semantics of Business Vocabulary and Rules (SBVR) specification from the Object Management Group provides a formal way to capture and express rules in a natural language-like form. In fact this facility enables the same rules to be expressed in alternative natural languages. The rules are represented in a computer model that can be used to analyze the rules for inconsistencies. The formal structure of the rules helps remove ambiguities. Eventually, it may be possible to use such rules to analyze business processes for potential risks and violations.

Enterprise Rules

Enterprise rules are those expressed by management to define constraints on the operation of the enterprise. These rules are referred to as business rules by a community of management consultants who specialize in the capture and application of rules expressed by executives. However, a reference to business rules is ambiguous outside that community.

An enterprise rule is a declarative expression of intent independent of specific business operations. For example, an enterprise rule might express that “any purchase of a personal computer or laptop computer must conform to an approved hardware and software configuration.” The rule does not define an action to be taken but rather a constraint on business operations. At the same time there may be degrees of enforcement from a level of discretion, where deviation might be authorized under special circumstances, to a level of absolute compliance in cases where there could be civil or criminal liability. The computer purchase rule we mentioned might have a level of enforcement that allows exceptions with prior approval—perhaps approval by the manager of the personal computer support activity.

Enterprise rules are a mechanism for managing the enterprise. Other management directives such as strategic initiatives, high-level business processes, organization structure, and allocation of resources are important aspects of enterprise management, but they have only indirect effect on how the enterprise actually operates. Enterprise rules define management controls that can have direct effect on daily operations as well as longer-term activities.

Ideally, executive management should create and modify enterprise rules, and the rules should have immediate effect on the operation of the business. For example, consider an enterprise rule that “returns must be in original packaging, accompanied by the original receipt and received within 30 days of the sale.” This rule might discourage some potential customers and alienate some current customers. The management might want to adopt a more accommodating return policy, such as “returns must be in original packaging suitable for resale, goods must be current stock items, and refunds are in the form of a company gift card.” In a large retail enterprise, this not only has direct effects on the product return activities but also on advertising, and it should be expressed to customers when they are considering a purchase.

Technology for deployment of enterprise rules is still evolving. A major step forward was accomplished with the adoption of the previously mentioned Semantics of Business Vocabulary and Rules (SBVR) specification. SBVR defines a standard computer-based modeling environment for enterprise rules. This formal, computer-based representation of rules provides a basis for automation of deployment. Since the model can support multiple vocabularies, the same rules and the concepts referenced in the rules might be expressed alternatively in English, German, French, or other natural languages or vernacular. This can be important for proper understanding of the rules throughout a global enterprise, particularly if the rules must be implemented in human activities. In addition, the models support capture of the meanings of the concepts being modeled, independent of the language used to express them.

Using SBVR, we might express the personal computer purchasing rule suggested earlier in the following form: It is obligatory that the equipment configuration of each personal computer is an approved configuration.

Obligatory, as defined by the SBVR specification, indicates that the rule is expected to be true but may have exceptions. The key concepts are the personal computer, the equipment configuration characteristic of the personal computer, and the approved configuration that identifies one or more specifications. Though this rule might be enforced by the purchasing department, it should be applied wherever the purchase of new personal computers is being considered.

Application of this rule might be manual or automated. Evaluation requires the ability to access approved configuration specifications and the ability to compare the configuration of the computer to be purchased against the approved configurations. Since automated comparison of the configuration specifications might be quite complex, the comparison might be done manually, or the approved configurations might each have an identifier that is used to specify the configuration of the computer being purchased. Purchase requests that are not specified with an approved configuration designation could be assumed to be noncompliant.

Consequently we have an enterprise rule that may be applied in many places throughout the enterprise where purchase requests are being prepared while the rule is enforced in the purchasing department prior to issue of a purchase order. In the various departments originating purchase requests, the rule should cause a noncompliant request to be directed to an appropriate level of approval so that when it reaches the purchasing department, the exception has already been approved.

However, note that the action taken from the rule differs depending on the context. In the originating departments, the purchase request should be routed for appropriate approval. In the purchasing department, if the nonconforming purchase request does not have the required exception authorization, the request is rejected. This highlights the difference between enterprise rules and production rules, discussed in the next subsection.

Enterprise rules should be managed centrally, in a rules repository or repositories for specific categories of rules (e.g., operating rules, product rules, contract terms), and their deployment should be tracked for accountability and to enable reliable deployment of changes. This provides the opportunity to ensure that rules are consistent and to support traceability of rule applications.

Production Rules

Production rules define an action or result to be produced under specified circumstances. These can be thought of as if-then or condition-action rules. For example, “if a customer automobile order includes the exterior appearance option, then add chrome trim and decals to the bill of materials.” Production rules might also be used to plan a trip or load a truck with packages of different sizes and shapes. In some cases, production rules implement enterprise rules in a particular context; in other cases they simply reflect the application of expertise, design requirements, or operating decisions appropriate to the particular situation. Where they implement enterprise rules, it would be desirable that there be traceability between an enterprise rules repository and the associated production rule to support change management and accountability.

Production rules are generally applied by a rules engine, as depicted in Figure 4.1. A rules engine is a software product that applies rules to a problem. Generally, the rules reside in the runtime environment and, on request, the data representing a problem to be evaluated is loaded into the rules engine working storage. A Rete network (pronounced ree-tee) is created to link the rules to the working storage for efficient processing. The rules engine determines whether any of the rule conditions are met. If the conditions of more than one rule are met, the rules engine has logic to decide which rule to “fire” (i.e., execute). When a rule fires, its action is performed. This action likely changes the data in working storage that defines the current situation; it may also cause some external effect. When the data changes, the conditions of a different subset of the rules may be met, and the rules engine again selects a rule to fire.

Figure 4.1. Production Rules Engine.

This general class of rules processing is called forward chaining because the action of each fired rule affects the selection of the next rule and the subsequent chain of actions. The generally accepted mechanism for evaluating, selecting, and firing rules is the Rete algorithm.

Production rules are used for planning and configuration. Most often they are used for complex configurations, such as computation of the payment for a health care claim or configuration of a complex product such as an automobile or a computer. For example, a rule may specify that “if a customer automobile order includes air conditioning, and if the order also includes an optional V-8 engine, then air conditioning compressor 1234 is added to the bill of materials.” Another rule may specify that “if air conditioning compressor 1234 is included, and the order also includes power windows or power door locks, then the alternator must be replaced by a heavy-duty alternator.”

Production rules might also be used for such computations as process planning, in-process inventory computation, design of experiments, or forecasting.

In general, a rules engine and an applicable set of rules are invoked at a particular point in a business process where there is a need for a complex computation to produce a desired result. This is typical of claims processing or product configuration. The rules engine is presented with all the relevant data, and the rules are applied. The rules engine returns a result, or it may return a failure to produce a desired result—the claim is invalid, the product cannot be configured, the solution cannot be reached.

The specification of production rules can be quite complex. The firing of some rules is dependent on the firing of other rules, as in the automobile configuration we mentioned. The rules engine defines a controlled environment in which the rules operate on a specific set of data that is affected only by the actions of the rules during the rules processing. For example, for automobile configuration, the rules engine would use the data that specify the requirements of the specific automobile to create a representation appropriate for rules processing, and it would produce a bill of materials in that specialized environment. It would not deal with other customer order information or other process variables. In addition, the rules engine introduces processing overhead for linking data to rules and rule selection. Consequently, a rules engine typically is not active throughout the execution of a business process but only at those points where appropriate, complex computations are required.

Alternatively, a process can be dynamically defined by rules. Where a process involves many variables and different actions for different results, production rules can actually determine the activities to be performed and their sequence as appropriate for the particular situation. Based on the state of the request and the work product, certain rules are available to fire. When one fires, it may perform an activity that changes the state of the subject matter, making other rules available to fire. In such a process, there is no obvious, predefined flow, just a set of rules. This differs from the typical rules engine because here activities are performed that are equivalent to activities in a conventional business process. Such processes can become very complex and difficult to manage, so this is not common practice.

Within conventional processes, if-then or condition-action rules are often applicable at many points in a process. These rules take the form of decision points, or gateways, of a process in BPMN terms. For example, a rule might state, “if acceptance of an order will cause the customer's credit limit to be exceeded, then the order must be rejected.” This rule is quite straightforward and does not require a rules engine to perform the computation. Sometimes the same rule may be applied at multiple points in different business processes. For example, instead of rejecting the order in our example, the rule might be changed to offer the customer an alternative payment option. The credit limit rule might be applied in an order-change process as well, and a rule change should be reflected in both processes.

Today many production rules are embedded in application logic. When there are relevant changes to business operations, programmers must search program code to identify decisions that embody the current production rules. This can be expensive, time consuming, and subject to errors. There are application modernization tools available for mining business rules from legacy applications, but this still requires human analysis to distinguish business rules from less significant program logic. Even when these decisions are implemented in automated business processes, they may be overlooked when a change is required. Specification and implementation of processes and applications using computer-based models can provide this traceability, both to identify where rules are applied and to trace from the application of a rule back to the business requirement.

Diagnostic Rules

Diagnostic rules are used to search for an answer, such as to find a diagnosis that is consistent with a set of symptoms. These solutions are generally developed with logic programming. Prolog is the best-known language for logic programming. The rule-processing mechanism is also called backward chaining because it starts with a result and searches for an explanation.

We might think of the basic form of a logic programming rule as then-if. For example, the “result” might be, “the car won't start.” We then look for potential reasons—in other words, things that, if true, would cause the car to not start. So, in a rather informal form, the rules might look something like this:

Here the question mark (?) represents a reference to the particular vehicle under consideration. More complex rules might reference additional relevant entities or values.

If implemented as Prolog statements, the execution would start with the first rule, where we are interested in finding a potential reason that Car-wont-start could be true. In order for Car-wont-start to be true, one of the subsequent statements must be true, i.e., Battery-dead or …. If we consider Battery-dead, we see that the next rule evaluates Battery-dead. If Lights-dont-go-on is true, then Battery-dead is true and the cause of Car-wont-start is found. If Lights-dont-go-on is false, then Battery-dead is false and we return to the first rule (we backtrack) to examine the next possibility: Flooded. The nesting of rules can be very complex. The ordering and structure of the rules determines the order in which questions are asked. For example, if Lights-dont-go-on is true, we have completed the search and we need not ask about Smell-gasoline or Fuel-gauge-shows-empty.

The example is quite trivial; it fails to demonstrate many capabilities of Prolog, it does not cover all possible causes of nonstarting car, and the result is fairly obvious. Much more complex problems can be addressed; among the most sophisticated is mathematical theorem proving.

The following are examples of potential business application areas for diagnostic rules:

• Diagnosis of failures or malfunctions in complex products or equipment
• Diagnosis of problems and causes of variance in complex manufacturing processes
• Analysis of designs for identification of product defects
• Analysis of causes of market trends

Note that rules engines that implement production rules (forward chaining) also usually include backward-chaining capabilities where an evaluation of a condition requires examination of other conditions on which it depends. Thus, in the automobile configuration example, instead of adding a heavy-duty alternator when air conditioning and power windows are ordered, the analysis might add a heavy-duty alternator if the power consumption is high, and power consumption might then be defined in terms of multiple other alternative factors. These rules engine facilities may not include backtracking, so they would not be able to search for alternative solutions. The use of forward and backward chaining together may make the design and maintenance of the rules more complex.

Logic programming is important for implementing complex searches. The programmer can focus attention on defining the rules and does not need to deal with the mechanics of backward chaining and backtracking. Nevertheless, logic programming does require special skills and attention to the order in which statements are executed.

Event Rules

Event rules define changes of state that are of interest. There are an infinite number of events that occur in the operation of an enterprise, so it is essential that the multitude of enterprise events be filtered down to those events that require consideration. Rules can be used to accomplish that filtering.

There are certain events that are of interest outside the normal operating activity. These events may be of interest simply for reporting certain activity, or they may be disruptive events, which can reflect a failure, a variance beyond normal limits, an opportunity, or a trend. The implications of disruptive events are discussed in Chapter 8.

From an information systems perspective, an event happens when a system is updated to reflect an associated change of state in the enterprise. So completion of an order entry is an event, issue of a purchase order is an event, an account reaching a zero balance is an event, completion of a business process activity is an event, shipment of a customer order is an event, and a power failure is an event (if there is a power-monitoring system to sense it).

Event notices are often managed in a publish and subscribe infrastructure whereby sources of events send the event notices to an event notification service, which redistributes the event notices to interested recipients. So event rules should be considered at three levels: at the event source, at a point of distribution, and in a resulting action.

Event source rules identify events of interest and restrict the publication of event notices to those events that have been identified as being of interest. For example, an order entry event might be of interest if the order is greater than $1 million or the salesperson exceeds her quota. Rules must limit the event notices so that the system is not flooded with event notices of no particular interest.

When an event notice is forwarded to an event notification service, rules define which subscribers should receive the notice. Some notices may have multiple recipients; some may have none—for example, “notify sales manager John Jones if a $1 million sale occurs in his region.” The notification service thus further limits the proliferation of notices and at the same time enables interested recipients to subscribe to notices of certain types of events, without the need to know where the notices originate. The distribution rules generally consider the type of event and associated information about the event.

Finally, recipients of event notices may use rules to decide what, if any, action is required. These rules might be characterized as event-condition-action (ECA) rules. They may consider the type of event and information associated with the event as well as other relevant information about the state of the enterprise or its environment and then perform an appropriate action. ECA rules are most often embedded in business processes or applications because they tend to stand alone. Rules may be used to evaluate the occurrence of related events, to infer the occurrence of a situation of interest. This is called complex event processing and involves specialized systems for event analysis. Complex events are discussed in Chapter 8.

In some ways these rules are similar to production rules because they are driven by changes in the state of the enterprise and they perform some relevant action. However, these rules operate in a loosely coupled, often distributed environment, and the actions taken are generally quite independent of the activity in which the precipitating event occurred.

Events generally drive side effects of primary activities. The primary activity is not concerned about others who are interested in the event. At the same time, the recipient is not required to know the source of the event notices. The difficulty of implementation is that though the recipient may expect to receive notices for all events of interest, (1) there may be unknown sources of potentially interesting events so that some events are not reported, and (2) a source may be applying an overly restrictive event condition so some events of interest are blocked.

Qualification Rules

Qualification rules define constraints on participation of people, services, or organizations in associated activities. These are of interest for process role assignments, for personnel assignments to positions in an organization structure, and for access authorization. Process roles are discussed in Chapter 3, access control roles in Chapter 6, and organizational positions in Chapter 7. Though rules can be used to express these various types of qualifications, the form of the rules and mechanisms of application vary. Qualification rules in an SOA context are discussed later in this chapter.

Data Integrity Rules

Data integrity rules are incorporated in data models and the design of databases. These rules may also be called business rules by developers of data models and designers of databases. These rules reflect constraints that exist in the real world. For example, a person cannot have a birth date in the future, and two people cannot have the same tax ID number. These rules do not change, and violation of these rules would indicate that the integrity of the associated database has been compromised. Consequently, in addition to being implemented in databases, these rules should be applied as data entry constraints and for validation of data received from other sources.

In some cases the rules incorporated in data models and databases are essentially enterprise rules—management decisions enforced by restrictions on data. This may be an effective way to enforce an enterprise rule, but rules embedded in database schema may not provide visibility and flexibility for the management of such rules. As discussed earlier, enterprise rules should be centrally managed and their deployment tracked.

Implications of SOA

The primary implications of SOA are a result of two characteristics: (1) similar capabilities are consolidated and (2) users of services may come from across the enterprise as well as the extended enterprise. Consolidation provides better focus for the application of rules, whereas an expanded user community increases the need for well-defined controls. Application of the different categories of business rules in an SOA environment is discussed in the following subsections.

Regulations and Enterprise Rules

Regulations should not be applied directly to the enterprise but should be translated into enterprise rules appropriate to the particular enterprise. There should, nevertheless, be clear traceability between the regulations and the enterprise rules. This is not unique to SOA.

However, SOA makes it more straightforward to determine where an enterprise rule applies precisely because the affected operations are consolidated. In general, enterprise rules affect certain capabilities, so SOA makes it easier to identify the service units and processes that must be held in compliance. In addition, where an enterprise rule affects many capabilities, implementation may be facilitated through creation of a shared service that applies the enterprise rules and is invoked at key points in the processes of affected services. This parallels the use of purchasing, accounting, and personnel services to control vendor selection, ensure control of financial records, and achieve consistency in personnel administration throughout the enterprise.

Even more focused control may be realized where there is a service that manages relevant master data (see the discussion of master data management in Chapter 5). Changes in the state of the enterprise are reflected in the master data. Rules are relevant when changes occur that violate the rules. Rules can be evaluated at the point at which the database is updated.

Again, traceability of rule deployment should be maintained so that the effects of the rules can be assessed and changes to rules can be quickly and consistently implemented.

Production and Diagnostic Rules

Where production or diagnostic rules are used to solve complex problems, they are applied by a rules engine or specialized language (e.g., Prolog). Essentially they provide a specialized capability that must include the expertise to maintain the rules. Thus the specialized capability should belong in a consolidated service. In some cases the rules and associated engine should be provided as a distinct service that is used in multiple contexts. Diagnostic services, in particular, may be useful to a variety of users.

Rules implemented with rules engines are relatively easy to locate because they are already separated from the processes that use them. Rules that define decisions within processes are not so visible. However, the consolidation of capabilities within services should help identify the processes where certain rules should be implemented to narrow the search and reduce the number of implementations for changes of a single rule.

Consolidation of capabilities may also provide greater opportunity for the codification of complex decisions. Generally, a rules engine is used at a point in a process where a complex problem is to be solved. Consolidation may yield the economies of scale that would justify a rules engine solution. For example, computation of billing for specialized services might be a time-consuming manual process performed by individual, field service units, whereas consolidation of the billing function as a shared service might justify the development of a rules-engine solution.

Event Rules

SOA facilitates the identification of sources of internal events of interest because capabilities are more likely consolidated and processes more consistent. At the same time, the current approach to publication of events requires that each event be explicitly programmed. In other words, a process that is the source of an event must be designed to recognize the event of interest and publish a notice. The result is that either there are many unnecessary event notices published in anticipation of interest or there is a need to modify processes every time a new event notice is needed.

Events occur when the state of the enterprise changes, just as enterprise rules apply when the state of the enterprise changes. If there is a service responsible for master data management, then, like enterprise rules, event rules could be evaluated when the master data are updated. This would allow a generalized capability to implement event triggers when there is at least one subscriber and remove the triggers when there are no subscribers. The result would be a high degree of flexibility in the detection of relevant events, with no unnecessary overhead for either evaluation of rules or creation of network traffic for events of no interest. Of course, for rules that detect violations or errors, detection of the condition in a master data update may occur after the fact and result in more difficult corrective action.

Qualification Rules

SOA involves three different applications of qualification rules: people qualifications, service policies, and access control rules.

People Qualifications

In business processes that engage people to perform tasks, there are rules in the form of attribute requirements and constraints that determine who is qualified to fill a role. Typically, the qualifications are applied to a local group of people that are members of the department responsible for the process. The rules may focus on the experience, training, or job functions of the people involved. They may also focus on the process context and subject matter, such as where there is value in having the same person do a sequence of related tasks, or the same person cannot be assigned to multiple tasks where there is a requirement for separation of duties. The form of expression depends on the BPMS product.

In an SOA, people who are candidates for a process role may come from various parts of the organization, as opposed to traditional processes, where they are within the same department. As a result there is a need for a consistent representation of people qualifications so that qualification rules can be applied consistently, regardless of where the person is in the organization.

Service Policies

Where there is a choice of alternative services, such as where one enterprise is selecting from alternative vendors, there is a need to determine which of the alternative services qualify. In this case, there could be requirements and capabilities expressed by both the requester and the provider. Each potential participant must determine whether the other potential participant qualifies to fill its role.

WS-Policy from OASIS is a standard language for expression of these requirements and capabilities policies. Policy expressions might specify an encryption algorithm to be used or the time allowed for a response. A service may specify alternative policies from which prospective service users may choose. Both service users and service providers may have policies regarding acceptable participants and exchanges. To collaborate, the participants must have a combination of policy alternatives that are complementary. The service users and service providers also must have a common vocabulary for expression of policies.

Access Control Rules

SOA increases the population and diversity of persons or processes accessing each service. This requires role-based access control (RBAC) to enable managers to control access and grant authority, without the need to get into extensive technical detail. Each employee may require authorization to access many operations and data in many systems to meet their responsibilities. With RBAC, rules specify the access authority of roles. These rules are specified by the manager responsible for protecting the operations and data, and he or she is able to focus on controlling what can be accessed if a user has been assigned to a particular role. The manager of an employee can then assign certain roles to an employee and the employee then has the authority granted to these roles. RBAC is discussed further in Chapter 6, in the discussion of security.

Data Integrity Rules

SOA does not affect the implementation of database integrity rules except that each service should apply the same rules to data received from other services, just as it would apply them to data entered by a human. A service should be designed to be used in a variety of contexts and cannot assume that all data inputs are reliable. Similarly, a service may use other services that could be independently upgraded or replaced in the future, resulting in incompatibility.

Rules Management

There is a need to manage some rules at an enterprise level. Production rules, diagnostic rules, and qualification rules are generally applicable to specific activities and can be managed at that level. However, enterprise rules, event rules, and data integrity rules may be applicable in different activities throughout the enterprise. A rules repository provides a central source in which the relationships between rules can be analyzed, the rules can be found to be incorporated in appropriate activities, and links can be maintained to identify where the rules are being applied.

Figure 4.2 illustrates a basic data model for a rules repository expressed in Unified Modeling Language (UML). UML modeling is discussed briefly in Chapter 5. Each rule is parsed (broken down) to identify the entities, attributes, and relationships referenced in the condition part of the rule. Rules are stored in the repository based on these associated condition elements.

Figure 4.2. Rules Repository Data Model.

Rules are of interest to a developer when the rule condition depends on an entity, relationships, or attributes that can be changed by the process or application under development. So process and application developers can retrieve relevant rules from the repository on that basis. The developer should then identify the process activity or the application component where the rule is applied. This provides the ability to determine whether a rule has been applied in all the right places and the ability to change the rule in all those places, if that becomes necessary. Of course, this assumes the existence of an enterprise logical data model (discussed in the next chapter) so that the entities, attributes, relationships, and rules can be expressed in consistent terms.

As depicted, rules operate on data—the attributes and relationships of business entities. Rules that are deployed to various activities throughout the enterprise are meaningless if their references to data are not understood across the enterprise. The development of a consistent Enterprise Logical Data Model is discussed in the next chapter.