Business Entities represent an abstraction of important (typically persistent) information within the business. Any
piece of information that is a property of something else is probably not a Business Entity in itself. For
example, ContactDetails is a property of Customer and therefore not a Business Entity in itself.
Information that is not stored but is created or determined on-demand (when necessary) is also probably not a Business
Entity. For example, product inventory numbers is certainly significant information, but this is not persistent
information. Any time somebody needs to know how many instances of a particular bar code are currently on the shelves
(or in the warehouse), this information will be calculated and then discarded. See: Term Definition: Business Entity.
Stakeholders use Business Entities to ensure that the information created and required by the organization is present
in the Artifact: Business Perspective (specifically the Artifact: Business Entity Model). An IT architect and business designer are responsible for identifying and describing
Business Entities, as well as for assessing the impact of organizational changes on the information created and
required by the business. Business Entities are also used by systems analysts and designers when describing system use
cases and identifying software entities, respectively.
Note that we say that Business Entities are manipulated by Business Actors/Roles, and in Artifact: Business Process Model we show this through invocations of operations on the Business Entity by Business
Roles. This depiction is itself a convenience -- in reality the operation invoked on the Business Entity may be through
the application of a tool (business activities/tasks) by the Business Role when executing a business process.
|
