Business Rule Management Facility: System Architect 2001

Why can't a standard repository work equally well as a means to manage business rules?

As the business-rule approach has risen in popularity, the number of vendors claiming that their tools support business rules has correspondingly increased. But exactly what the vendors mean by that claim isn’t always clear. For these reasons, I laid a groundwork in my last several columns for evaluating business-rule products, to determine just how well they support business-rule management and enforcement.

Proceeding from that foundation, I can answer a question that has been needling me for some time: Why can’t a standard repository serve as a business-rule management facility? With their extensibility and intelligent browsers and their report writing, version control, and generation facilities, repositories seem to fit the bill perfectly. To test this hypothesis, I decided to extend Popkin Software and Systems Inc.’s System Architect 2001 version 7.1.12’s metamodel to support business rules. (See Figure 1)

FIGURE 1 Business-rule metamodel.

Click here for PDF of figure

I chose System Architect 2001 (SA) for a number of reasons. First, SA is both a repository and a CASE tool. To support the business-rule product evaluation, I had already developed the object and data models that the other business-rule products required in SA. So, it was natural to continue the evaluation of its repository capabilities as a business-rule management facility.

Second, its extensibility is unmatched by any other product. Adding new meta-object types (or what SA calls definition types) is an easy exercise once you learn the metamodel extension syntax. SA comes with an extremely robust metamodel of its own that supports almost every major analysis and design methodology. Although you can’t delete any of SA’s standard meta-objects, you can enhance them with additional attributes and hide ones that are not appropriate for your environment.

Third, SA provides an easy-to-use browser for navigating the “uses” and “referenced by” hierarchies. It lets you quickly see all the business terms that reference a given business concept and any related business policies and business rules. It shows how the data or object class models support each business rule.

Given these repository features, I decided that SA could serve as a “stand-in” for other, possibly better known, repository products.

Now, let’s examine how well SA fares in each category.

Discovery

A business-rule management facility must provide an environment for documenting, browsing, and reporting on business rules. The interface must be easy for both the subject matter expert and the business-rule analyst to use. SA provides this type of facility if the metamodel is properly extended. Be careful in deciding how the relationships between definition types are established. The relationship properties should be defined within the definition type from which it is most natural to enter the information. For example, the business terms that are used to identify a business concept are defined within the business concept definition, as are the related business policies. Now, when the user selects a specific business concept and expands its node in the browser, he can easily view all the associated business terms and policies. Because a business policy definition points to its related business rules, the user can continue to navigate through to related business rules by expanding the node for a specific business policy.

Users can find any other definitions pointing to the one that interests them by selecting the “referenced by” option. For example, if you select the “referenced by” option for a business concept, the application will display any data model entities that support that business concept, because the reference between the data model entity definition type and the business-concept definition type is defined through the entity.

SA’s report writer is also very easy to use. I created a “business concepts” report that listed all the business terms, policies, and rules associated with a business concept in about 15 minutes.

One of the features of a business-rule management facility that I did not find in SA is the ability to build business policy and rule statements through a point-and-click kind of wizard. The statements are simply text to SA. Any business concepts the statement identifies still require manual linking to the associated business-policy or business-rule definitions.

Business Area “Line of Business” Subscription

Different lines of business may establish different business rules for the same business concept. Therefore, a business-rule management facility must be able to identify the set of business rules to which a business organization subscribes. SA easily handles this requirement, as organization is one of its standard definition types. When I defined the metamodel for the business-rule definition type, I included a link to the organization definition type. Doing so simplified maintenance of the information about which organizations subscribe to which business rules.

Conflict Management

A business-rule management environment must be able to discover conflicts between business rules and track the conflict resolution. To support this requirement in SA, I added the Business Rule Group definition type, which identifies the business rules that have some sort of relationship to one another. I identified two types of business-rule groups: conflict and variation. A conflict would threaten the enterprise if unresolved. Variations aren’t as dire; they are alternative approaches to implementing the same business policy, but do not put the enterprise at risk if they continue to coexist. SA provides, for a conflicting business-rule group, a link to a change request so you can track the conflict’s resolution.

Business-Rule Classification

Several business rule classification schemes exist — thanks to standards organizations (such as the Business Rules Group), business rule product designers, or (possibly) your own organization — that can help you analyze and understand each business rule. I defined the Business Rule Group’s classification scheme as a lookup attribute for the business rule definition type, enabling proper classification of each business rule.

Information Resource Object Mapping

It is important to be able to trace how the information resource and technology environment supports each business concept, policy, or rule. SA easily supports this requirement; its metamodel incorporates most of the popular information resource methodologies and technologies. For example, its metamodel enables linking object-class and data-model components to tables in a relational database.

Change Management

Business policies and rules change over time and a business-rules management facility must be able to track those changes. Versioning and release management are essential features. Unfortunately, SA, out of the box, does not provide either facility. PVCS from Merant International Ltd. provides some level of versioning, but you cannot use it to easily track and view versions from within SA.

SA does provide mechanisms to track change requests. Unfortunately, the standard metamodel did not anticipate the need to track changes at the definition level. Change requests can be easily associated with symbols on a diagram, but not to definitions.

This exercise has convinced me that my initial belief that repositories should be considered as potential business-rule management facilities is supportable. If your enterprise has already invested in a repository, you should determine whether it can be extended to meet your business-rule management needs. If not, you might consider System Architect 2001.