Business Object Modeling - an Introduction

 

In this article, I shall describe what is meant by business object modeling, where it comes from, the benefits of this approach, some basic principles and when it should be used. 

Business object modeling describes a static representation of the business domain under consideration in a project. It is static as it shows the important entities, their 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).

The term business object modeling is used inconsistently and may also be referred to as Domain object modeling or even conceptual object modeling. It should not be confused with enterprise modeling 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.

 

History

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

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

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
  (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 it

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.

 

In conclusion, business object modeling 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.

 

Please comment below if you enjoyed this article, email to a friend or make suggestions for new articles on this subject.