Rules Centralization

How can business rules be abstracted and centrally governed?

Problem The same business rules may apply across different business services, leading to redundancy and governance challenges.
Solution The storage and management of business rules are positioned within a dedicated architectural extension from where they can be centrally accessed and maintained.
Application The use of a business rules management system or engine is employed and accessed via system agents or a dedicated service.	Impacts Services are subjected to increased performance overhead, risk, and architectural dependency.
Principles Service Reusability	Architecture Inventory

Table 6.21 – Profile summary for the Rules Centralization pattern.

Problem

The workflow logic within any given business process is driven by and structured around rules specific to how the logic must be carried out, as per policies, regulations, and preferences of the organization. Individual business service capabilities frequently must carry out their encapsulated logic in accordance with these rules.

It is not uncommon for the same rule to be applied to different scenarios involving different business entities. This results in a need to incorporate the same rule within different bodies of service logic. As an organization changes over time, so do certain business rules. This can lead to modifications within individual entity business services as well as business process logic encapsulated by task services or otherwise (including the occasional utility service).

Having to revisit multiple services each time a business rule changes is counter productive and wasteful.

Figure 6.92 – Just two business rules can find their way into several different business services and, in this case, even a utility service. A change to either rule will therefore impact multiple services.

Solution

Business rules can be physically abstracted into a dedicated part of the architecture under the management of specialized rules engines and platforms. This centralizes access to business rule logic and avoids redundancy. It further centralizes the governance of business rules so that they can be modified and evolved from a single location.

Figure 6.93 – All business rules are encapsulated by a single rules service accessed at runtime by other services that need to retrieve or apply business rule logic. (Service agents are also commonly used to provide native access to abstracted rules., as explained shortly.)

Application

Different business rules management systems exist, each providing a relatively proprietary runtime and administration platform. A central service can be established to provide an official access point for the creation, modification, retrieval, and application of business rules at runtime.

Modern runtime platforms also offer native rules repositories and processing logic that is made accessible via a set of system agents and APIs. This allows any service to interface with business rules-related logic without having to compose a separate service.

Impacts

Because this pattern is applied across an entire service inventory, it can impact an architecture in several ways:

•     While this design pattern achieves the centralization of business rules data within an inventory, it also decentralizes business logic associated with business services. For example, business rules related to the processing of invoices would normally be encapsulated by an Invoice entity service. However, this pattern would remove move those business rules into a separate location.

•     The performance requirements of affected services are increased, due to the need for business rules to be retrieved or applied at runtime. Caching mechanisms can alleviate this impact to an extent (usually when rules are temporarily stored as state information for a particular service composition).

•     If existing runtime platform features cannot be leveraged to establish centralized rules management, this pattern generally results in the introduction of a separate business rules management product. This extension can increase the size, complexity, and overall operational cost of a technology architecture and must furthermore be sufficiently reliable to consistently accommodate service usage patterns. A rules management system prone to runtime failure can paralyze an entire service inventory.

•     Accessing centralized business rules via native system agents and APIs will impose tight architectural dependencies upon services. If many business services use these runtime features, the overall service inventory could become Òlocked inÓ to a particular vendor platform, thereby reducing the extent to which Vendor-Agnostic Context can be achieved.

•     Because the actual business rule logic is physically separated, the scope of logic encapsulated by several business service capabilities is incomplete (as per their parent contexts) and their overall autonomy is decreased.

Another issue worth noting is the actual management of centralized business rules. Often a technical administrator is in charge of the actual rules system, but multiple business domain experts may be needed to maintain the business rules themselves. This can lead to ownership challenges in that the custodian of a business service must also be involved with the maintenance of a subset of the business rules within the central rules repository in addition to the governance of the business service itself.

Relationships

Business rules can be found just about anywhere within a typical service-oriented solution, which is why the abstraction and centralization of rules data can affect the content of a service contract, as per the Validation Abstraction pattern.

Because this pattern may result in the creation of specialized rules utility services, it is naturally related to the Agnostic Context and Cross-Inventory Utility Layer patterns. As a reusable utility service, a rules service may need to encapsulate proprietary rules engines or products, which can lead to the need for the Legacy Wrapper pattern and which also ties into the regulatory influence of Canonical Resources.

Security and business policies will often need to incorporate or introduce rules, which is why this pattern may be applied together with Policy Centralization and Security Centralization.

Figure 6.94 – The Rules Centralization pattern establishes utility logic that may need to encapsulate legacy systems in order to provide central rules management features.

Centralized business rules are commonly leveraged to increase the sophistication with which ESB products carry out messaging, routing, and brokerage-related functions (Figure 6.x). In ESB environments, the variation of this pattern resulting in native agents and APIs is more common than the creation of dedicated rules services.

Similarly, this pattern can be leveraged by orchestration products so that business rule logic can be incorporated into workflow and composition logic (Figure 6.x).

Figure 6.95 – One of the more sophisticated extensions to the base Enterprise Service Bus compound pattern (covered in Chapter 9) is that of native Rules Centralization, allowing much of the core ESB functions to be driven by business rule logic.

Figure 6.96 – As with an ESB platform, business rules processing can also be part of an orchestration environment, which is why this pattern is considered an optional extension of the core Orchestration compound pattern (also described in Chapter 9).

Case Study Example

Case study content is not available on this Web site.