Continue in 2 seconds

Adventures in Universal Modeling

By
  • Susan F. Martin, Doreen Evans
Published
  • May 01 1999, 1:00am EDT
More in

A recent article in DM Review1 was the first time we had heard the term "universal data model." But it wasn't the first time we'd worked with one. A year ago, one of our company's clients asked for help in implementing a generalized, abstract model from IBM. The model includes, for example, a single entity, PARTY, instead of entities for CUSTOMER, EMPLOYEE, DEPARTMENT and so forth. This puts it squarely in the realm of universal models. The model was built over many years with the help of many insurance organizations around the world and is intended to support the constructs needed by any and all insurance companies. The idea is that insurance organizations using the model can save time and money by leveraging the use of common database structures, rather than having to reinvent the wheel each time they develop a new system.

This type of model has another important benefit. Once implemented, it can easily support changes to business rules. When you use a universal model as the basis of your database design, you can add new types of relationships or change existing ones simply by adding new allowable values to the relationship tables. Terry Moriarty, who uses the term dynamic model to refer to what we're calling a universal model, describes this benefit in detail in a recent article.2

This all sounds good, but this article isn't intended as an advertisement for universal models. Rather it's an attempt to show how a real project team struggled to obtain benefit from a real universal data model. We believe what we learned will be useful for any organization trying to incorporate universal models successfully.

The Project

Our client had purchased their universal model about one year prior to our being called in. Some work had been done, but basically the model had not been touched for over six months. The client wanted to give it another try to see if they could leverage the investment already made. One of our tasks would be to discover why the model had been so difficult for them to incorporate. The first step was to learn about the model itself.

The model provides a business architecture from which you can describe applications for insurance companies. The data model consists of a highly generalized set of entities and attributes that support the insurance industry. It describes the "what to know" that the insurance industry deals with, for example, persons, agreements and so forth.

Similar to the universal data models described in the DM Review article (and in the related book by the same authors3), the data model we were to work with is highly abstract. For people and organizations, it includes a single entity, PARTY, with two sub-types, PERSON and ORGANIZATION. It is in the relationship of a PARTY entity with another PARTY entity that a role is taken on. This role information is captured in the type of the relationship. Each organization specifies the types, and therefore the roles, which apply to its business policy.

For example, a PERSON entity can be related to another PERSON with a role of DEPENDENT. An ORGANIZATION can be related to another ORGANIZATION with a role of DEPARTMENT. A PERSON can be related to an ORGANIZATION with a role of EMPLOYEE and, perhaps, also a role of CUSTOMER. Figure 1 illustrates the basic PARTY structure.


Figure 1: PARTY View

The Problem

Our client agreed that such a generalized model held many advantages. It would be flexible and easy to extend. New roles need only be added to allow new relationship types between PARTY entities. So why hadn't the model been used?

The problem, as we eventually discovered, was that the model seemed to have no relation to the client's business. They were building a group health care enrollment system. Where were the members and their dependents? Where were their plan choices? Where were the rules governing which employee groups could select which plans? Our client did not see their business in the universal models. Once we understood that this was the roadblock, we set about defining a solution.

Step 1: Developing Three Levels of Models

The universal model, while very complete and detailed, did not address the capture of business requirements. Without those requirements, our client felt at a loss as to which parts of the universal model to use, or whether its basic constructs needed to be modified to capture their business-specific rules. This, we discovered, was the key issue that prevented the effective use of the model.

The solution was to develop three levels of models:

Business-level models would allow us to gather knowledge about the business using familiar terms such as client, member or group plan. This level of modeling would also allow us to capture information about business processes and the organizations within the business that participated in those processes.

These models would be built using normal entity relationship modeling and process flow modeling. Participants did not need to reference or even be aware of the universal models we would ultimately be building. They could communicate in their own business terms. (Obviously, the more you work with universal models the more your requirements-gathering effort will be informed by that knowledge.)

Generic-level models would translate our business information into universal model components. Thus our business terms of client and member would become party; our group plan would become agreement. At this level we would also discover the elementary business functions that would apply to our business processes and organize those functions into a function flow.

** Click Here for:
Figure 2: Process for Building Business Requirements and Generic Models


These models would be built using customized diagram and definition types, since we would need information oriented specifically to the universal model structures.

Implementation-level models would move the generic models into a physical description. Since we were using a modeling tool, we could generate SQL and skeleton code from these models.

Step 2: Selecting A Tool

We agreed that we needed a modeling tool to capture the business requirements, the basic universal model constructs and the project-specific models. The tool would need to be easy to customize, since we would build several new diagram types and add new definitions to capture the information we wanted. And the tool would need to be repository-based. Pictures would not be enough; we also needed to build and capture definition information.

We had worked extensively with System Architect from Popkin Software & Systems and from experience knew that it would provide all the support needed. This coupled with the fact that the client had already selected System Architect as its enterprise modeling tool made the choice easy. System Architect fit the criteria we had established. Its repository base meant that we could store information, track the relationships we needed, and report on that information effectively. Its ability to be easily customized meant that we could tailor it to provide diagrams and definitions with the exact properties we wanted. And since the client already been using System Architect for other purposes, they wouldn't need to spend time learning a new tool while trying to learn a new approach to modeling.

We then took the universal model definitions and populated a System Architect repository with this information. Thus we created what we termed our " Universal Base" repository. We'd be able to draw on this information when we built our project models.

Step 3: Defining a Process

We agreed that if the client were to have any hope of successfully incorporating universal models into their requirements and analysis practices over the long term, they would need to have a process to follow. As the project progressed, we built a step-by-step process for gathering requirements and for transitioning to the universal models. The process we ultimately settled on looked like this:

There were four major process phases: 1) specifying business requirements, 2) translating the requirements into universal models, 3) designing the solution, and 4) maintaining the company's base information. The second process phase, translating the requirements into universal models, holds three other sub- processes: analyze system requirements, extract and reuse universal components, and build universal-compliant models.

As we developed the process, we found it was extremely important to emphasize the requirements phase. Here is where our clients felt comfortable and could grasp what entities and relationships would be needed and what the business process flow was intended to be. We realized that it was crucial to capture the business owners' understanding and to capture it in their terms, not in universal modeling terms. As a consequence, we built these requirements models without worrying about how the universal models would be represented or implemented.

Once we had the basic requirements, we would work to translate our requirements into universal-compliant constructs. How did those requirements get expressed in the universal models?

As we've said earlier, entities in a universal model are highly generalized and are, therefore, likely to have different names than the entities identified with the business users during requirements analysis. For example, our client had identified a Member entity, and listed "Name" as an attribute within that entity. In finding the corresponding universal entity, they needed Person, Party and Party Name to fully represent their business concept of "Member." Once these candidate entities were identified, we merged them into the project repository.

The next step was to build the universal-compliant view of the data using an entity-relation model that had been customized to accommodate universal model constructs. We built this model in two versions: a standard view and an "exploded" view, which we used to reveal the individual types and roles each relationship could participate in. This view was useful because it was easier for the end users to read, understand, and verify.

Figure 3 illustrates the changes as we moved from a requirements model to a universal model of the same information. We started out with four entities: Member (an employee who signs up for a group health plan according to the benefit group she/he fits into), Dependent, Employer and Benefit Group. We stored quite a bit of information about the Member, including the name, the beneficiary and the number of months of pre- existing credit. This last piece of information was necessary due to state regulations that mandated that any months of coverage that the member had before coming to the current employer's group plan must be factored into calculations of which health problems would be eligible for coverage.

** Click here for:

Figure 3: Requirements Model and Universal Model of Same Information


In the universal model we migrated to five entities. Name information was pulled out into a separate entity PARTY NAME. Thus it could be applied to any person (Member, Beneficiary, Dependent) or any organization (Employer or Benefit Group). Our information about Members, Employers and so forth, would be represented by the super-type PARTY and the sub-types PERSON and ORGANIZATION.

Key relationships were tracked in a PARTY RELATIONSHIP entity. Within that entity, there is a Relationship Type attribute. For each relationship we wanted to track, we created type/role information and tracked it in the relationship type. Thus we had types of Is-Member-Of, Is-Physician-Of and so forth. Martial status, which had originally been tracked in an attribute, was now tracked by a type Is- Spouse-Of. One benefit of this scheme is that it can handle multiple marriages because it tracks the start date and end date of each relationship.

Notice that we still have a Months_Pre-existing_Credit attribute in our PERSON entity. This was determined to be a piece of information that could not be tracked in any other manner. We considered building a relationship to each person's previous employer(s), but discovered we could not guarantee having access to this information.

Maintaining Company Base Information

As we worked with the universal model, we found that we needed to develop a repository for the customer's own definitions. In other words, we needed to build a client-specific universal model. For example, our insurance company needed to have an attribute for Months_Pre-existing_Credit previously described.

Similarly, if what the universal model calls "Initial Name" is always called "First Name" at your organization, then you should change the name of that attribute permanently. However, we also think it's important to maintain the original starting point for your universal models. That's why our process included both a UNIVERSAL BASE repository and a CUSTOMER BASE repository.

Using a universal model is not easy, especially the first time out. Just because the model is termed "universal" does not mean that it is at a high level or even that it is business oriented. It means that the model has been abstracted and generalized to such an extent that it will be able to support the needs of the business over many years and that it will be capable of supporting changes without re-writing the structures.

Users of universal models must recognize this fact and begin by developing business- oriented models so that they can gather knowledge from their business users using their own terms. This business-oriented or requirements model will be the model at the highest level. The universal model comes next, and is created by building a subset of the complete universal model constructs. At the lowest level, you build an implementation model.

The effort requires careful analysis of each business's individual characteristics and processes, but it ultimately rewards the organization with models that stand the test of time.

References

1 "Is Your Organization Too Unique to Use Universal Data Models?" Len Silverston. DM Review. September, 1998.

2 Moriarty, Terry. "Relationship Rules." Intelligent Enterprise. March 30, 1999.

3 Silverston, Inmon, Graziano. The Data Model Resource Book. John Wiley Sons. 1997.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access