Using Party and Party Role Concepts to Represent Business Relationships in a Data Model: Overview

Every business has a complex set of relationships with multiple companies and individuals from diverse backgrounds and roles. For example, retail companies sell products to customers. They have contractual relationships with selling partners that help facilitate the sales of their goods and services to customers. They have contractual relationships with suppliers that manufacture and/or provide the goods that support sales activities and with vendors that deliver services to their customers.

As an information architect, it is important to document these business concepts in the Conceptual and Logical Data Models, which are the first steps in abstracting the business to an “information layer.” Working closely with a business, we gain a thorough understanding of their processes, terminology, and business relationships. Unfortunately, business terminology is often defined, and used, differently across the enterprise landscape (e.g., business areas, systems, etc.). Data models provide a means to create a standardized language for the “information layer,” thereby enabling improved sharing and reporting of information across this landscape.

Modeling Problem

One of the core challenges that data modelers encounter is modeling relationships between an enterprise-level company and its various customers, partners, suppliers, and vendors. I have observed a lack of consistency within the data modeling community on how to best approach this problem. Logical data models (LDMs) vary based on the adherence to standards, the modeler’s expertise, the model’s intended audience, and the model’s usage during a project’s requirement phase and/or design phase.

Customer, supplier, partner, and vendor are distinct and meaningful terms to the business. In seeking clarity of concepts and flexibility in their design, information architects identify the commonality of these terms and the specific role each serves. In addition, a customer is either an individual or an organization. Suppliers, partners, and even the company entity itself represent organizations. In data modeling, information architects abstract these concepts and introduce the concepts of “Party” and “Party Role.”

Design Options

The introduction of the Party and Party Role concepts doesn’t totally solve the problem. As with any modeling approach, there are strengths and weaknesses.  “The Data Model Resource Book: Volume 3: Universal Patterns for Data Modeling” provides excellent guidance for developing data models. For the purposes of this blog, I will discuss the book’s declarative role patterns – Levels 1 and 3.

Declarative Role – Level 1

In this data modeling pattern, the customer, supplier, partner, and vendor roles are explicitly represented.

Declarative Role Level 1 - Piraeus Consulting

This Pattern Should Be Used When:

– A well-defined set of declarative roles are identified and known by the business.

– An enterprise views a person or organization as being synonymous with what each does or how each acts.

– There is a need to describe the business requirements in a simple way.

– There is a need to show a simple, unambiguous diagram to the business and other IT professionals.

– The roles in the business remain static and don’t change.

– Each person or organization plays one and only one role, and this is true at the same time or over time.

What Are the Weaknesses of This Pattern?

– It would not be suitable in a dynamic environment where new role types are added frequently or when roles are not well understood.

– Information attributes may be repeated.

– It is very difficult to see the whole picture of an individual or organization. For example, a supplier may also be your customer.

Declarative Role – Level 3

This data modeling pattern identifies Individual and Organization as subtypes of Party. Party Role is also subtyped into various roles (e.g., customer, partner, etc.).

Declarative Role - Level 3

This Pattern Should Be Used When:

– An enterprise has a dynamic business environment where declarative roles get added and changed as new requirements emerge over time.

– There is a need to effectively maintain and manage all roles.

– An enterprise wants to allow a flexible way to categorize the different declarative roles contained within the Party Role via the addition of Role Type.

– There is a need to capture common relationships and attributes at the Party Role level by maintaining data about a Party only once even though the Party may play many roles.

– There is a need to maintain a more complete picture of each Party with all the roles that they play, along with the associated data about each role.

– There is a need to relate other entities to the Party Role .

What Are the Weaknesses of This Pattern?

– By adding the Party Role concept, you are adding a level of generalization that is uncomfortable for many enterprises.

– It obscures that certain roles are for people, some for organizations, and others for parties.

– If parties do not ever play more than one role, then, the advantage of reducing redundancy may not be a factor.


Although more complex, the Declarative Role Level 3 pattern is my preferred approach. It provides key flexibility needed in this ever-changing competitive market. Overall, its strengths outweigh its weaknesses. However, its weaknesses need to be fully understood and documented. We recommend the use of various techniques to hide Party abstraction from the business. Techniques include the use of smaller, unambiguous data models (e.g., submodels) and “views” in the implemented solution. Remember, the business wants to see “customer”, “supplier”, “partner”, and “vendor”, not “party”.


In summary, the use of “Party” and “Party Role” in the data modeling of business relationships provides clarity in terminology, commonality in attribution and flexibility in design. This approach allows an information architect to be agile in the ever-changing business landscape.

This blog post is the first in a series that discusses the critical role of the information architect in enabling data sharing and reporting across the enterprise. Stay tuned for more!

By Wayne Johnson| Senior Consultant, Data & Development