Introduction

Business entities represent "things" consumed or produced by business activities. A business entity represents something of value to the enterprise, therefore the business entity is likely persistent. Business entities may represent real-world objects within the IT architecture, customer or report for example, and as such they will have relationships with many other entities within the architecture. These business entities in general will have attributes reflecting their purpose, a representation of a physical object like a customer for example, but should not have attributes that define how and by whom it should be used. The workflow attributes and rules are separate objects themselves. Also see the definition for Business Entity.

When modeling a business the entities are often representations of real-world objects—we are modeling the business as reflected in and supported by the information technology (IT) after all. The physical aspects of the business need to be reflected in the IT environment. Note however that IT concepts such as storage do not appear at the business level, they show up in the Logical Entity Model.

An entity is used to model information and associated behavior that typically must be stored (but this architectural decision is not made until the logical level model). Entities are used to hold and update information about some phenomenon, such as an event, a person, or some real-life object. They are usually persistent, having attributes and relationships needed for a long period, sometimes for the life of the system.

An entity is usually not specific to one business activity; sometimes, an entity is not even specific to the IT architecture (or enterprise) itself. The values of its attributes and relationships are often derived from an actor, perhaps external to the enterprise. An entity may also be needed to help perform internal tasks,and entities can have complicated behavior. However, unlike other objects, this behavior is strongly related to the phenomenon the entity represents. Entities are independent of the environment (the actors and activities), but represent the key concepts of the system being modeled. Typical examples of entities in a bank are Account and Customer. In a retail sales store, examples are Product and Customer.

Entities provide a point of view from which to understand the system because they show the data structure, which can help in understanding what the system is supposed to offer its users.

Finding Entities

Entities represent information in the IT architecture; they are typically used to represent the key concepts the business activities consume or produce. Entities are frequently passive and persistent. Their main responsibilities are to persist (store) and manage information in the system.

A frequent source for finding entities are the Glossary (developed during requirements), the Scope and Context Diagram, and (descriptions in) the Business Process Model. Look for the nouns and they will likely be entities.

Attributes

An attribute of an entity represents a piece of information about it that is important to know. An attribute has an attribute type (e.g. "string" or "integer"). Each attribute and attribute type has a name.

An entity normally holds different pieces of information that describe some of its characteristics. Such pieces of information can either be described implicitly in the textual description of the entity or modeled explicitly as an attribute of the entity.

An attribute is of a certain type. An attribute has a name, preferably a noun that describes the attribute's role in relation to the entity. An attribute type can be more or less primitive, for example a simple number or string. Different entities can have attributes with identical structures. Those attributes should then share a description; that is, they should share an attribute type.

Attributes vs. Entities

A key consideration in modeling the entities is always the question: entity or attribute? In other words, is the "thing" in question important and involved enough to be modeled as an entity, or should it simply be an attribute of another entity? As always when doing architectures the short answer is "it depends". It depends, in this case, upon how the "thing" is used within the IT architecture or enterprise. Is it simply a bit of information or are there other attributes about the thing that need to be understood and used?

If the phenomenon you wish to model is not used by any other entity, you can model it as an attribute of an entity, or even as a relationship between entities. On the other hand, if the phenomenon is used by any other entity in the model, or if there are attributes about the phenomenon required, then you must model it as a separate entity.

Operations

To perform a business activity, the actor (or service) uses various Tasks to manipulate business entities. The actor invokes tasks, or service tasks are invoked, that are part of the business process. These tasks create or manipulate the business entities by invoking the entity's operations (thinking of the entity as an "object" in the Object Oriented design sense). Operations are named and may optionally have parameters. This invocation is normally shown as a message being sent to the object from a Task.

Operations can be defined informally or in detail, depending on the importance or required level of detail. A "more detailed" description might describe a behavior sequence that tells which attributes and relationships are dealt with during its performance, how of other objects are contacted, and how it is terminated.

Characteristics of a Good Business Entity

• Its name and description are clear and understandable;
• Business entity relationships do not depend on each other;
• Each defined relationship is used in the workflow of at least one activity/task;
• All "things" in the business, such as products, documents, contracts, and so on, are modeled as business entities;
• The entity participates in at least one business activity.

Business Events

Business events can be used to notify interested parties (including other business entities) of a change in state of the business entity. The creation and destruction of a business entity may be significant and result in business events. If you have defined a state machine for an entity, examine the defined states. Each transition is a potential business event. Also inspect the attributes and operations of the business entity. Significant operations that are used infrequently may have a business event associated with them. Changes to important attributes may trigger an event. Business process patterns and business entity patterns may also provide insight into useful business events. For example, if a business entity must be approved before being used further, a <something> Approved business event may be useful to notify other parties. For more information on finding business events, see Guideline: Business Event.