In this article, I shall describe what is meant by business object modelling, where it comes from, the benefits of this approach, some basic principles and when it should be used.
Business object modelling describes a static representation of the business domain under consideration in a project. It is static as it shows the important entities, relationships and attributes but does not show how these change over time.
See Use Cases – an Introduction for an example of a technique for a ‘dynamic’ or functional view of a system. See useful business analysis industry templates
if you are interested in templates that you can use on your projects.
Table of Contents
Business Object Modelling
The below is a business object model diagram example. The business object model example shows example of entities (the boxes in the diagram) and relationships (the lines in the diagram).
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.
History of Business Object Modelling
Its origins lie with more technical disciplines which include logical and physical data models. These techniques were used to design relational database management systems (RDBMS) which is what most people mean when they talk about databases.
In the last twenty years, class models and object models have also emerged which show both the static view of objects but also the functional view. If you ignore the functional aspect of class model, the data model and class model notations differ but can be used to represent the same sorts of relationships between entities and their attributes.
The example shown at the start of the article is a class model without any methods (which are the functional elements).
Benefits of Business Object Modelling
The business object model shows a different perspective on the problem domain. It is neither a good nor a bad technique, it merely shows a different perspective which can answer questions, raise more questions and further the understanding of the business domain under study.
It will provide questions or answers which can be fed back into other perspectives such as the use case model (or any functional view). It is normal to switch between different models of the problem domain many times in order to increase understanding.
It is very useful for guiding more detailed activities which follow such as creating a data dictionary (and a physical data model) which can be referenced when designing screens, reports and interfaces with other systems.
Principles / Approach to Business Object Modelling
These are a few guidelines to start when a business object model is being produced:
- Make it understandable for the business;
- Use terms they are familiar with wherever possible. Warning: it is not uncommon for terms used in the business to be ambiguous and have more than one meaning. In this instance, it is essential to have distinct names and entities for each meaning;
- Include a glossary template
; - This helps identify double meanings and ensures agreement amongst stakeholders.
- Keep it simple, start with core entities and relationships;
- Supply attributes when to resolve disagreement over the entities and their relationships.
One challenge can be in presenting it to the stakeholders – it can be intimidating and will not be well received by stakeholders who are uncomfortable with abstract views. This is easily resolved – there is no need to ever show a stakeholder the class model.
The business object model can be something that you build up and use to ask questions but retain for your own use. For example, all of the relationships on a business object model can be turned into statements and questions if you are looking for confirmation.
Will the customer normally have more than one order?
Do you ever have customers who have no orders? If so, why?
When To Use Business Object Modelling
This approach is particularly good for a green field project where there are no existing models that you can start with.
Inevitably, it is not useful in projects that are primarily functional and involve very little data. It is most helpful where there are many different entities or classes with complex inter-relationships.
It will be less useful for small adaptations to existing system unless it is poorly documented and it is needed to understand existing system.
Conclusion – Business Object Modelling
In conclusion, business object modelling is another tool you should have in your arsenal of business analyst techniques. It provides you a different perspective on the business problem under study which will help improve your understanding and may well be essential for later, more detailed business analysis work such as designing reports.
You should always start with a high level view of core entities and relationships and make sure no entities are ambiguous or have double meanings.