Overview

In the Unified Architecture Method (UAM), Business Entity Models are used to define the structure of the (likely persistent) entities used by the "system"; a conceptual level model is defined.  At this level of modeling we are not concerned with the design of tables in a database, the physical storage of the entities, nor the constructs for modeling referential integrity (constraints and triggers) and stored procedures.

Business Entity Models are constructed to provide standard definitions for key business entities (such as customer and employee) that are used by all activities in a business (i.e. the "system" under study). These models also define the "owner" of the business entity and activities that create or otherwise manipulate the entity.

This guideline describes the model elements used to construct a Business Entity Model for the "system". Note that the data modeling representations contained in this guideline are based upon the UML 2.0.

Note: Since UAM can model the complete enterprise (i.e. EA, or a business line), the level of detail to be included in the model is a judgment call of the IT architect, based upon:

• The objective of the architecture effort;
• The size of the "system" under study (i.e. enterprise (EA) or business line/ domain, etc.);
• Time and resource constraints.

Levels of Entity Models

As in UAM, which also applies to entity models, there are three level entity models: conceptual (i.e. business level), logical (i.e. logical level), and physical (i.e. technical level), see: Concept: Data Modeling.  These levels of modeling reflect the different levels of modeling defined in UAM, see Concept: Architecture Perspectives and Viewpoints. Summaries of logical entity modeling (i.e. the Logical Perspective) and technical data modeling (i.e. the Technology Perspective) are provided in sections below for reference, but also see: Guideline: Logical Entity Model and Guideline: Technical Entity Model. A definition of conceptual data modeling is provided in Wikipedia: Conceptual Schema and a description of how to do it is provided in Conceptual Data Modeling. 

Business Entity Model

The Business Entity Model captures well-defined representations of all the business entities produced or consumed by business activities. The entities are defined, along with the relationships between them required to support the business. This model is computationally independent; it has no notions of storage or databases or other logical or physical level concepts and constructs. It is a conceptual model.

This conceptual model identifies the high level key business entities and their relationships that is effect define the scope of the "system" to be modeled. These key business entities are defined using the attributes elements of the Business Entity Model viewpoint language.

Finding business entities is as simple as finding the nouns in descriptions (by business people) of the business and business processes and business plans and strategies that describe the system under study. What is important however is coalescing on standard names and definitions for these entities and also in identifying and describing the associations between these entities that are needed to support the business activities. For example, a retail business sells product to customers, therefore a product-customer association is needed, to enable the tracking and analysis of the products specific customers have purchased, and product trends and other analysis in support of the business.

A simple example model is shown below. At the business level we are many focused on identifying the entities, agreeing upon their precise definitions and describing required relationships between them. Optionally, attributes may be defined if they are important in understanding the entity and how it fits into the business.

Depending upon the scope, context and objectives of the IT architecture, the IT architect may decide to provide much more detail in the Business Entity Model, as shown in the example below.

Ensure that the entities are defined at the same level of abstraction, that definitions are agreed, are clear and concise and that all required relationships are defined and understood. For more information on finding and modeling business entities see: Guideline: Business Entity and Guideline: Business Perspective Views.

Logical Entity Model Summary 

In logical entity modeling, the architect is concerned with identifying the key entities and relationships that capture the critical information that the "system" needs to persist.  During the analysis and definition of required entities, the architect needs to ensure that the entities defined, along with relationship between them, will adequately support the system's activities (processes and tasks) defined at the logical level.  During the Define Logical Entity Model task, the architect defines the set of entities in the model and the logical structure needed to persist them in data stores.

This set of persistent elements in the Logical Entity Model provides a view that, although different from the traditional logical data model, meets many of the same needs; however it is for use by IT architects in understanding the larger picture of the "system". These model elements accurately reflect the data that must be persisted, however not all of the attributes and required relationships may be defined. The Logical Entity Model is however an excellent starting point for the creation of a logical data model or even a physical data model.

For more information on modeling logical entities see: Guideline: Logical Entity, Guideline: Logical Entity Model and Guideline: Logical Perspective Views.

Technical Entity Model Summary

The Technical Entity Model is the final stage of development of the data aspect for the "system".  In the Technical Data Model technical choices, namely design patterns and standards that support both the logical view and the business view. There may also be some refinement of the data model, but the focus is on design patterns and technical standards including hardware and software choices (depending upon the scope and objectives of the IT architecture).  

For more information on the Technical Entity Model see: Guideline: Technical Entity, Guideline: Technical Entity Model and Guideline: Technical Perspective Views.