Dynamic Models for Dynamic Businesses
Resolving the disparity between application infrastructures is a key element in customer relationship management

Terry Moriarty                
February, 1999

This year I took my first trip abroad to Australia and New Zealand. The ambience of these countries was wonderful, but there were obvious differences in culture and behaviors from what I’ve observed in the U.S. Each country has developed its own standards with respect to how it manages its infrastructure. Who really drives on the wrong side of the street — Americans or the British Commonwealth? Why is the speed limit in Australia equivalent to approximately 50 miles per hour, yet I can safely cruise along at 70 in parts of the U.S.? Is this an Australian plot to trap lead-footed, American tourists? Most cultures aren’t planned; they evolve over time. For the most part, they draw their boundaries and, in isolationist style, focus on making what goes on inside work. Countries develop their own unique infrastructure to deal with the elements and terrain Mother Nature dealt them. They look outside their realm only when they need to draw strength from alliances with others, either for economic survival or to ward off aggressors. A country may find the infrastructure that works so well at home is totally incompatible with that of another country. These infrastructure issues can become barriers to forging strong partnerships if the countries don’t address their divergence.

Most applications evolve the same way that cultures do. They reside within an application portfolio carved into individual fiefdoms, scoped to meet the needs of a specific product line, market segment, or function within an enterprise’s lines of business. The implicit assumption is that each application can stand on its own with little or no influence from other applications. Consequently, each application-development team is free to assemble its own infrastructure in terms of the built-in technology and how it structures the application’s data and processes. The problems of mismatched infrastructures, particularly with disparate data designs, come to light when the team discovers that its application has to interface with others.

The isolationist approach to application development has introduced another type of data disparity into the application portfolio: redundant database entries for the same real-world entity. If a person interacts with many lines of business in different capacities, that person’s name, address, phone number, and email address may be recorded separately in each application database. For example, the same person may be an employee within the human resources system, a shareholder within the shareholder management system, and a separate customer in the investment and bankcard systems.

Even within an application’s domain, an organization may maintain redundant data if it melds together a person’s data with the data about the roles he or she plays within the business. If the application’s data model has roles as entities—such as account officer, customer, and vendor—the data about the people filling those roles may be in each table redundantly if the roles overlap (that is, if the person fills more than one of these roles). While the account officer manages several customer portfolios, can that employee also be a customer? Are any of your customers also your vendors or suppliers? Within the scope of an individual application, the answers to these questions may be no. But when these questions are posed to a widening scope within the enterprise, at some point, the response will be yes. The infrastructure that meets its stakeholders’ immediate needs so well becomes a barrier when an organization decides to compile an enterprisewide knowledge base of its essential business concepts (such as customers, products, competition, market and economic conditions, and resource use).

Dynamic Customer Relationship Management

When countries need to resolve their infrastructure differences, they call on an international standards body to facilitate the process. But even when they find a solution, achieving compliance with the new standard may be hazardous and costly. No matter how laudable the solution may be, changing a country’s infrastructure is no easy feat, as those who have been involved in the introduction of the euro know. Not everyone feels that change is warranted.

When an organization decides to integrate its disparate application infrastructures, it establishes its own standards bodies to define a common solution. It must establish frameworks through which it can identify, analyze, and select alternative solutions. One such framework is the enterprise model, which provides an organizationwide view of its business data, process, and information distribution needs. When an organization combines the data and technology architectures, a blueprint emerges through which an integrated technology infrastructure supports the flow of information across the enterprise.

An enterprise model takes time to develop, so you may want to consider buying one of the available general business models as a starting point. These commercially available business models are amenable to change so that they can foster a dynamic business environment. For this reason, I call these highly abstract business models dynamic models (see my December 15, 1998, column, “Building the Customer”). These models are based on concepts common to all business: people and organizations, product and service offerings, market segments, locators, and finance and service requests. The dynamic model is well situated to provide the flexibility an organization’s information systems must have to manage its relationships with its customers successfully.

The dynamic model provides a number of building blocks for constructing the data necessary to manage the customer relationships. Let’s start by exploring the people and organizations about which your company must know in order to conduct business. If your organization has been building applications around roles, the first step is to examine these roles to identify the data describing persons or organizations, independent of how they fit into your business. Data specific to a person includes name, birthdate, points of contact, social security number, and passport number. Organization-specific information includes company structure (such as whether it is incorporated), the type of business it engages in, and the industry in which it competes. The organization may also have its own “personal” data, such as its Dun and Bradstreet number and tax identifier.

The dynamic business model defines an organization as any group of people who come together for a common purpose or share a common interest. This broad definition encompasses not only commercial endeavors, but also government bodies, associations or clubs, households, and families.

Because either people or organizations can fill business roles such as customer and shareholder, the dynamic model represents the roles as subtypes of a common general entity. There may be no business term for this generic entity, so you will probably have to create one. “Party,” “involved party,” “interested party,” and “persona” are just some of the names I’ve seen in business models for this entity. I prefer the term “business party.”

The Power of the Dynamic Model

When analysts emphasize the roles that business parties assume, they often model only the customer in depth; they assume that the organization fills the supplier role. Likewise, when analyzing the human resources department, we tend to model the employer role with the understanding that the employer is our organization. The dynamic model, however, makes no assumptions about who is in what roles. It treats the organization under analysis as just another business party. Consequently, your organization, along with all its subsidiaries, internal units, and employees are the business parties. Any other person or organization involved in delivering your product offerings, such as your suppliers, sales channels, and regulators, are also business parties.

The dynamic model’s power comes from its neutrality. It has the ability to represent any organization. You could potentially use the same structures to represent your organization as a customer of some other business party, or your customer as a competitor’s customer. For this reason, you must give each business party a unique identifier to associate it with all the roles it assumes.

As I’ve mentioned, one of the greatest challenges your organization faces in managing the information about people and organizations is ensuring that it does not record multiple entries for the same business party in the enterprise’s knowledge base. Assigning a unique identifier to each business party is not enough to prevent the creation of duplicate entries, however. People often forget the ID your organization assigns them. Consequently, you must use data that is more familiar to the person to improve your ability to locate the business party’s existing record, such as name, address, phone number, and so on. Unfortunately, many applications bury this type of information in text, which can be difficult to search. The dynamic model holds this kind of data in more easily searchable ways.

Breaking Down the Dynamic Model

The data model for the business party concept (see my figure “Business Party Data Model” at www.intelligententerprise. com) brings together the business requirements for supporting business parties within the context of the dynamic business model.

Figure 1

Figure 1 uses all the constructs that provide the flexibility inherent in the dynamic model: business rule category entities, inheritance hierarchies, and metadata transformed into business data.

The category entities specify many of the business rules that govern the behavior of the actual entities containing data. Within this data model, notice the “business party,” “business party reference,” and “business party name usage” entities. You can see inheritance hierarchies for business parties at both the specification level (through the business party category entity) and at the actual data level (through the business party entity). We often show category entity subtyping for communication purposes. However, we will never implement these subtypes as separate tables in the enterprise’s knowledge base; instead, they will be represented as entries in their respective category table. On the other hand, the subtypes under the business party entity are candidates to become their own table because they have their own data from their sibling subtypes or participate in relationships (with other entities) on their own.

Finally, the business party reference category and business party reference represent a situation where metadata, which resides in the enterprise repository, finds its way into the business model. Business party reference is any identifier assigned to a business party that is “near” unique that we can use to locate a specific business party instance. Externally assigned identifiers may not uniquely identify a single business party on their own, they narrow down the set of business party entries to a manageable set. Because the references in which the business is interested can change over time, the business party category entity lets you specify new references on the fly. It contains attributes commonly found about a data element in repositories, including name, data type, and format.

Just as culture and societal behavior are the building blocks of a country, the business party concept provides the basis of the customer building blocks. The dynamic model can help you eliminate redundant database entries and other problems stemming from disparate application infrastructure. Depending on what country you’re in, you may have to deal with driving on the “wrong” side of the road. But you have a good chance of leading your company down the right road with the dynamic model.

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.