Business Object Modelling – An Introduction

The term business object modelling is used inconsistently and may also be referred to as domain object modelling or even conceptual object modelling. It should not be confused with enterprise modelling or enterprise architecture as these are different and cover the entire enterprise from many different perspectives whereas the business object model is limited to the domain in the current project.

The business object model shows a representation of the main data items (entities) used within an organisation and of the business rules that govern the relationships between these entities.

Creating an business object model offers some significant benefits to a business analyst, including a better understanding of the data that is used within the organisation and may need to be stored and manipulated within a computer system, and a stronger grasp of the business rules that govern the creation, use and deletion of data by the organisation.

Some business analysts shy away from data modelling, thinking that it belongs more to the work of systems analysts and developers, but I do not think this attitude is correct. The business analyst is the person with the close relationship with the business, and so is in a much better position than developers to understand the data and how it is used.

The concept of entities, as the name of this technique suggests, entity relationship models have two fundamental components – entities and relationships. An entity is ‘something of interest to the system, about which data is to be held’.

An entity is also referred to as a business object. The BIZBOK defines a business object as:

A  representation of a thing active in the business domain, including at least its business name and definition, attributes, behaviour, relationships and constraints, that may represent, for example, a person, place or concept.

Entities (business object examples) can be:

• Physical – e.g. car,
• Conceptual – e.g. a car body type
• Active – e.g. a car service

Relationships between entities – entities are related to (have connections or associations with). For example, one instance of car can have a relationship with many instances of service. The ‘crow’s foot’ indicates the ‘cardinality’, or degree, of the relationship.

As well as cardinality, we can also indicate on our model whether the relationship is an optional one.

For example, a service must be associated with a car but a car does not have to have a service associated with it; the relationship is said to be optional. If we think about this, it is obviously true, since a new car might not yet have been serviced.

If we think about the relationship between car and service a bit more, though, we will realise that their relationship is actually more like a many-to-many one.