Relationship Rules
Following the patterns will help you implement business rule changes faster

Terry Moriarty                
March 30 1999, Volume 2 - Number 5

Today’s business environment can be extremely dynamic. Fueled by mergers and acquisitions, evolving product lines, new market entries, and ever-changing regulations, our business partners’ world looks downright chaotic to IT. Consequently, IT is always seeking new tools it can use to respond rapidly to the organization’s changing business rules. The dynamic business model is emerging as a powerful approach to managing those business rules that you can express as data in a database. When developers build applications to provide the flexibility inherent in the dynamic business model, we can accommodate business rule changes easily by simply editing the database’s category and allowable tables.

Even with its enormous potential for managing an enterprise’s business rules, however, the dynamic business model has at least one major drawback. The model is abstract so that it can depict the data structures necessary to engage in business — any business. As a result, you can’t read the business rules specific to your organization from the data model diagram. To illustrate this issue, let’s compare two data models intended to support business rules that specify valid business party relationships (see my sidebar “Business Party Relationship Business Rules” on the Intelligent Enterprise Web site). It’s easy to see that these models are very different, even though they are intended to support the same business rules.

FIGURE 1 Business party relationship literal data model.
The Literal Data Model

The first model (see Figure 1, page 68) represents a literal data model; all the business rules are depicted on the diagram. It’s very easy to read and validate the business rules using only the data model’s diagram. The model also highlights some important constraints about how different types of business parties can interact. Even a quick glance at the diagram reveals that there are some relationships between individuals only (such as spousal and parental) or between organizations only (such as reporting structure). Other relationships are between organizations and individuals (including household membership, assignments, and employment).

For example, an individual does not have to be a member of a household, but for a household to exist, it must have at least one individual as a member. Furthermore, only individuals can be members of a household. Likewise, an individual can be employed by only one legal entity (company or corporation), but you can assign the individual to multiple internal units within that legal entity. Each symbol in the modeling notation represents a single business rule category, which communicates a single fact. Consequently, the diagram serves as the modeler’s primary communication vehicle for extracting, documenting, and validating an organization’s business rules.

If the literal data model can communicate so many of your organization’s business rules, why would you want to migrate to a dynamic business model so abstract that most of the important business rules are no longer depicted on the diagram? Because the dynamic model allows the level of flexibility that will let systems complying with it readily adapt to changing business rules. Let’s consider what happens to systems built under the literal data model. Suppose the business decides it needs to know whether its employees have jobs outside the organization. The business is changing the business rule “an individual can be an employee of only one legal entity” to “an individual can be an employee of many legal entities.” What’s the impact of this change on your data management environment?

First, you must update the data model to reflect the change by modifying the maximum cardinality on the “employs/is employed by” relationship to “many.” Likewise, you must modify your information systems model to resolve the many-to-many relationship between an individual and legal entity by introducing a new “employment” entity.

Second, if you have built any applications using this model that enforce this business rule, you must modify them to reflect the new requirement. Regardless of the approach you use to implement the business rule (foreign key constraint, trigger, stored procedure, or object class method), the business rule is, for all practical purposes, embedded in code. To change the business rule, you must change some level of code. It takes more time to complete the modifications necessary to support the new business rule when that rule has been hardcoded into the application or its database. Finally, you must convert any existing data into the new database design. That’s a lot of work for a simple change in cardinality.

The Dynamic Business Model

In contrast to the literal model, the dynamic business model excels in its ability to support changing business rules. The business party relationship rules depicted in the literal model are translated into entries in the business party category, business party relationship category, and allowable business party relationship role entities. (See Figure 2.) The business rules expressed through the relationship cardinality notation are also represented through data in the category entity. (See my column in the March 9, 1999, issue for a discussion of the business party relationship pattern).

FIGURE 2 Business party relationship dynamic business model pattern. 

The sample instance tables for the business party relationship category and allowable business party relationship role entities illustrate how you can “datify” business rules. The business party relationship category includes all the data required to express a single type of relationship. Each instance is equal to a relationship line on the literal model. Each relationship has its own unique name, as well as the names of the primary and secondary roles. You express the business rules about optionality and concurrent relationships for both the primary and secondary roles through the optionality indicator and maximum concurrency attributes allowed. The optionality indicator states whether or not a business party must participate in one of these types of relationships in order to exist as a business party. If it is not required to participate in the relationship, then the optionality indicator generally reads “true.” Although “true” is the normal setting for this attribute, in our example the business stated that it didn’t want to know about any households that didn’t have any members. Therefore, for household membership, the optionality is set as “false.” A household must participate in at least one membership relationship with one individual.

Table 1 Business Party relationship category sample instance entity.

Table 2 Allowable business party relationship role entity sample instance table.

The maximum side of the cardinality is also held as data in the business party relationship category table, in the maximum allowable concurrency attribute, which identifies whether a business party can participate in multiple business party relationships of the same category. The allowed values are “one” if a business party can participate in only one relationship category at a time, “many” if the business party can be involved in multiple instances of the same type of relationship concurrently, and “specific” if the business party is limited to a specific number of concurrent relationships of the same category. The allowable role entity supports the business rules that state which roles a business party category can assume in a specific business party relationship category. For example, both individuals and legal entities can be shareholders (or owners) of a legal entity. But only a legal entity can be owned.

When you use the dynamic business model as the basis of database and application design, you can add new types of business party relationships or modify existing ones easily by adding new records to the category and allowable tables. These structures can also support different variations of the same, basic business rule. For example, the business rule that requires you to identify one household member for every household applies to the upscale market segment. The managers of this business area want to send mail only to a specific person in the household; however, the people responsible for the mass-market segment are willing to address their solicitations to the household name (for example, the Moriarty family). You can define these variations as separate category instances.

How can you adopt the dynamic business model without losing the literal model’s communication abilities? You can represent many of the business concepts depicted on the literal model’s diagram as subtypes of one of the more generic entities in the dynamic business models. Analysts will have to end their dependency on the model diagram as their primary communication vehicle. They can augment their analysis toolkit with alternative approaches, such as the sample instance tables for category and allowable entities. I keep dreaming that some vendor will provide the ability to construct a literal model that we can use to populate the dynamic business model’s business rule tables automatically.

A Disclaimer

When I talk about the benefits derived from incorporating the dynamic business model into an organization’s information systems architecture, IT professionals often express concerns at the thought of letting the business users directly change the business rules that are enforced through the application portfolio. They fear that the changes will not be tested properly before being put into production. These are legitimate concerns that a robust business rule management environment – which includes version control, release management, and testing environment – addresses. I find that the business professionals responsible for managing, modifying, and implementing business rules are aware of the needs for procedures to control the business rule release introduction into the production environment. They are willing to assume the responsibility of managing their business rules when provided with an environment that lets them implement their business rule changes faster.

Terry Moriarty, president of Inastrol, a San Francisco-based information management consultancy, specializes in customer relationship information and metadata management. Her common business models have been used as the basis of customer models for companies within the financial services, telecommunication, software/hardware technology manufacturing, and retail consumer product industries. You can reach her at terry@inastrol.com.