Business Rule Management Facility: System Architect 2001
Business
Rule Management Facility: System Architect 2001
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.
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.
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.
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.
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.
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.
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.
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.
Terry Moriarty, president of Inastrol, a San Francisco-based information management consultancy, specializes in customer relationship information and metadata management. She authored Enterprise View (originally the Repository Report and later the Data Architect) column for Database Programming & Design. You can reach her via email at terry@inastrol.com.
Copyright © 2000 Terry Moriarty ALL RIGHTS RESERVED No Reproduction without permission