Account Business Pattern

Requirements, Design, Architecture

Account Business Pattern

Problem

Most business systems, data warehouses, and various other information systems are riddled with problems and confusion because of the concepts of Customer and Membership. That is, even within the same organization there is confusion about the definition of a Customer.

Context

The author of this pattern contends that there is no such concrete concept of a Customer or Member. The author contends that these 'states' are derived based on the type of activities certain parties (entities) are permitted to conduct. Hence, the Account Pattern seeks to provide a mechanism that resolves the confusion.

In everyday business language, we use the term Customer and Member. However, we really are referring to a Party, whether it is an Organization or a Person. When we say, he or she is a Customer, we are really saying that the Person is transacting with us. However, there is often confusion and conflict about when is a Customer really a Customer. Also, when is a Customer no longer a Customer? Within one organization the answers to these questions differ. Is it no wonder why Customer Relationship Management Systems are screwed up?

Forces

Different parts of an organization must analyze activity and opportunities. For example, Marketing wants to see who has not purchased in a period of time and who might be interested while Sales wants to know the demographics of current sales. Information about a single Party can be stored once. Who cares whether Acme Grommets is a Customer, a Vendor, or a Competitor? Why keep redundant information in three separate databases? Worse yet, not even knowing they are the same entity!

Solution

Do not keep a Customer or Member concept. Make Customer and Member an instance of a 'Role'. Make role an attribute of an Account. The Account object keeps a reference to the Party. In this way, the Party can have several Accounts, each with a different (or even the same) role.

The above is an extreme simplification. However, the fundamental concept is the Account. The Account is the primary tool for managing business. It is the instrument that accrues historical information. It is the Account's state (status) that a business cares about. For example, one part of the business may define ANY party with an Account where the Role of the Account is Customer. Another part of the same business may define a Customer as any Party with an Account where the Role is Customer and the status is Active.

Use Fowler's Accountability Pattern to provide further refinements, e.g. restricting what a Role can do - Purchase. Also, Locations may be associated with the Account rather than the Party. For example, one Account's Billing Address may be X while another Account's Billing Address is Y.

Related Patterns and Known Uses

As stated above, see Fowler's Accountability Pattern. This pattern has been used widely in the author's practice for several clients.