THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

Today, models are available that you can use to jumpstart your modeling effort. Why start from scratch, when a starter model exists? Some model developers, such as David Hay, Len Silverson, Bill Inmon, and William Fowler, have published many of their models in books. Larger corporations, such as IBM and NCR, have built entire lines of businesses around their models, with a price that reflects that commitment.

Models are available to meet your budget, from the price of a book to hundreds of thousands of dollars. With so much intellectual capital invested by the architects of these models, wouldn't your organization benefit from using one?

The criticism I hear most often is that these models are too abstract. They don't use the terms of your organization. Often, they don't even use the standard terminology of your industry. If I had a dollar for every time I heard "I can't read my company in this model," I'd be rich.

The beauty of a universal model is its independence of any specific company or industry. These models represent what it takes to be a business, any business. The terms used are universal to any community engaged in the exchange of goods and services. If you were to model what is taught in business schools, you'd end up with something that looks a lot like one of these models. In fact, completely different groups of people engaged in the modeling process, completely independently of one another, have all emerged with amazingly similar data models. There must be some sort of truth lurking behind these models. Just as a thorough understanding of fundamental business concepts helps you better engage in business, it also supports the information structures that underlie any business. Since universal models are grounded in the basic architecture of any business, they can be readily adapted to almost any organization.

For example, Table 1 provides a list of fundamental business concepts that exist in almost any successful business. Although the terms may differ a little among models, the same business concepts pop up in almost every universal model. So you may find Interested Party, Involved Party, or simply Party used instead of Business Party. Others prefer the term Location, Address, or Geography for what I call Locator. What's important is not the term, but the concept as expressed through the definition.

Table 1 Fundamental business concepts from a universal model.

You probably don't see the terms that your organization or industry uses for these business concepts. To use the universal model effectively, you must inventory your own business concepts and map your vocabulary into the fundamental business concepts.

Table 2 provides such a mapping for the terms found in the EU-Rent case study from the Business Rules Group's initial paper, "Defining Business Rules - What Are They Really?"

Table 2 Mapping of EU-Rent terms into the fundamental business concepts.

Interesting insights emerge when you map your terms into these business concepts. Most organizations realize that they don't have a term that means "a person or organization." We have a universal business concept for which no one has taken the time to assign a term ... which is why terms like Business Party get invented. What's more interesting is that information that really is about a specific person or organization is buried behind the role that those business parties can assume (such as renter, branch, branch manager, or loyalty program member). Have you ever wondered why you have to keep filling out your name and address on so many forms when you do business with the same organization? It may be because we've built our business processes around the roles that business parties play, not around the business party. Thus, we have our first source of redundant data: the names, addresses, and phone numbers of the people and organizations with which we do business.

We can also see that many of our terms really represent events that occur during the life of a sales transaction. For EU-Rent, the sale starts with a reservation event that creates the basic terms and conditions of the car rental request (who wants to rent the car, when they want to pick it up and return it, what class of car they want to reserve, what discounts are available, and the expected price for the rental).

The rental agreement is not legally binding yet. It's possible that the prospective renter won't show up or that EU-Rent will not have the requested car class on hand. The rental agreement represents the intent to execute an actual car rental under the terms specified at the time of the reservation, but neither side can be forced to abide by those terms.

When the renter shows up to pick up the reserved car, the rental agreement is completed by identifying the specific car assigned to the customer, including any additional options the customer has selected, such as insurance coverage, and calculating the expected rental fees. When the customer signs the contract documentation, the agreement becomes legally binding. However, the sales event is not complete until the renter returns the car and pays for the services EU-Rent provided. The sales event is actually a major event that involves a series of subevents: the reservation, the rental, and the return.

Many people purchase a universal model because they think they will be able to skip the business analysis phase of a project. After all, the requirements are all there inside the model, right? Sorry, but nothing is further from the truth. You can use the model to help you analyze your business, but it can't replace that analysis.

Knowing that you have to inventory your business concepts and map them into the universal model might dampen your enthusiasm. If using a model increases the time it takes to understand your business, what possible benefit can it provide?

Enterprise Integration

If your organization has several autonomous product lines or markets, chances are they have evolved independently of one another. Each has become a community with its own culture, processes, business rules, and vocabulary. Should your organization want to examine itself from an enterprisewide perspective, as occurs with a CRM initiative, these fiefdoms produce smoke screens that inhibit its progress. Likewise, if your company has embarked on a strategy of growth through mergers and acquisitions, the enterprise view becomes even fuzzier with each new community absorbed into the enterprise. The fundamental business concepts of a universal model provide a framework for integrating the disparate terms in your various lines of business. The universal model's concepts are a catalog of neutral terms. By mapping your terms into these business concepts, you can see how your various organizations overlap. Yet, you aren't requiring any line of business to change its words. You gain an enterprisewide view while avoiding the resistance that often meets the parent organization that tries to force its communities to change their vocabularies.

Multiple Benefits

A universal model bestows additional benefits when used as the basis of your enterprise model and the design of your enterprise data store. For one, the mapping process becomes the cornerstone of your data stewardship program. As a result, your enterprise integration effort provides stewardship at the business-concept level. You mine your application portfolio to discover how the model's concepts manifest in each business line's applications and databases. The mappings between an application's data and the enterprise data store become the requirements for transforming each business line's data into the format specified through the universal model. As application data migrates to the enterprise data store, it becomes the enterprise's single source of authoritative and integrated data. Over time, you get another benefit: An enterprisewide data hub emerges as you rearchitect applications to service their data requirements through the enterprise data store.

A universal data model is adaptable to the needs of different industries and organizations through its entity typing facility. Every primary entity in the model has a corresponding Type entity that records the mapping between your organization's terms and the fundamental business concepts. The typing facility provides the flexibility you need to rapidly assimilate the next business line's concepts into the enterprise data store.

Likewise, the data necessary to support new products and markets can be readily incorporated into the enterprise data store. Changes to the enterprise model and enterprise data store are required only when an entirely new business concept arises.

A greater level of flexibility is achievable when your universal model is also dynamic. The typing facility handles only business concepts that are represented as primary entities in the universal data model. A dynamic data model expands this facility to support additional business rule types, such as those that govern the behavior of entity relationships, allowed values for attributes, the expressions that define attribute derivation rules, or the qualification rules for business states and the allowed transitions between business states. Some models even provide the ability to dynamically define new attributes to the enterprise data store.

An enterprise data store application validates its data against the business rules defined through the dynamic model's business rule facilities. New business rules can be added and existing ones modified because the code to support these types of business rules are held as data in database tables, no longer hard-coded using relational database facilities.

The Real Payoff

A certain level of flexibility comes from using universal and dynamic models as the basis of database design. But the real payoff comes when applications are built to exploit the fundamental business concepts and business rule facilities. When a database is designed to use the facilities of a dynamic, universal data model, the database environment can rapidly accommodate changing business rules, often without requiring any structural database changes. But if applications are still built using traditional approaches where the support of most business rules, including data validation rules, is embedded within application code, the impact of changing business rules on the application portfolio can still be massive. Why build a database that can accommodate changes in five minutes, if you still need three months to reflect those changes in application code?

If your enterprise's objective is to cut the time to market for new products and pricing plans, for entering new markets, or for assimilating other organizations that it acquires, you can't afford to keep building applications the old way. Applications built around the universal model's fundamental business concepts and the business rule facilities that accompany dynamic models are nimbler. They know how to handle the business rules as they are modified within the database. With the demand to drive the enterprise view of a customer to every enterprise customer touchpoint, you can't afford to continue building applications using design approaches that resist change.

Expect Resistance

Business executives and decision makers are very accepting toward universal data models. They have no problem seeing their business within the structures of one of these models, which is why I've seen so many business subject matter experts embrace these models, stating, "Finally someone has given me something that supports my business." I wish I could say the same about those organizations' IT groups.

I've encountered resistance across the board from within IT - from data modelers who are used to developing models from scratch, to DBAs whose gut reaction is that these types of database can't possibly perform in their environment, to application architects and developers who honestly believe that data designs should be optimized to meet their application's specific requirements. They all represent stumbling blocks on the road to successfully incorporating a universal model into your technical environment. Many of the issues IT raises are legitimate. As the champion of the model, you must anticipate these concerns and be prepared to address them.

If one of the primary uses of data models within your organization is to teach your IT staff your company's business, you don't want to buy a universal model. However, if the objective is to position your enterprise to better accommodate change, a universal model has a place in your enterprise's strategy. It's worth the fight. Prepare to do battle.