Business Object Modeling – an Introduction

 

businessobjectmodel1

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.

It's only fair to share...
Share on Facebook4Digg thisBuffer this pageShare on LinkedIn0Share on Google+0Share on VKTweet about this on TwitterShare on Tumblr0Pin on Pinterest0Share on Yummly0Flattr the authorShare on Reddit0Print this pageShare on StumbleUpon0Email this to someone

About Alex Papworth

11 Responses to “Business Object Modeling – an Introduction”

Read below or add a comment...

  1. Ezra says:

    Hi Alex,

    I find your article very usefull and clear. From my perspective I can see how this tool would be advantages to the DB and systems architect team with an indirect beneft further down the line for effective systems development. It definetly ensure the full scope of a domain be considered. Allowing the business analyst to come up with questions that might not have been seen without it.

    If you could spare me the patience, I would however like to know the purpose of a business model as appose to a business object model, because me research leads me to believe the is a difference, and more so on the audience it is intended for?

    Regards
    Ezra

  2. Robert says:

    Ah, yes Alex, I was clearly unable to read properly on that day :-).

    Your highlighted section is spot on and a very good caution.

    How have you found DB designers response to being presented with such a diagram. Always open arms?

    Regards
    Robert

  3. Robert says:

    Maybe I’ve been dealing with the wrong people, but I’m not sure I’ve come across too many business people that would find this type of diagram exciting. Possibly even a turn off.

    Understanding data is important, I agree, but this form of presentation would alienate many of my business users and would deem it “too technical”.

    Would you present this to the business for sign off? And even if they did how many would have understood it even after a walkthrough?

    This is just another “BA tool” derived/adapted from the world of IT, yet we seem to harp on about being business focused…. Sorry, haven’t got an answer – maybe just a whinge on this point!

    • Alex P says:

      HI Robert

      I agree with your concerns, they are well founded – many stakeholders would be completely intimidated by this. However this is just a tool and you can use it without even showing it to the stakeholders but use it to validate your analysis and drive questions.
      As I say in the article:

      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?

      One set of stakeholders who WILL appreciate it (if it is done well) is the designers, especially those in charge of database design.

      There are other tools that I find very useful and would use but might be very cautious on presenting to the stakeholders – state diagrams are a case in point.

      Hope this helps.

      I’d be interested to debate more if you still disagree with its use

      Alex

  4. Yanic says:

    Hi Alex,

    Yes my question has been answered, thanks!

  5. Yanic says:

    Hi Alex,

    I’m also an OO person, just like you (as you can see from my link :o)

    I’ve always wondered what to make of this thing called OO analysis…

    I’ve read most of the available reading material on OOA (well, up until a few years ago), but almost every example I saw was basically just a conceptual data model under the guise of an object model (or class model as some call it), or it wasn’t an analysis model at all but rather some kind of design model.

    If we can agree that ‘analysis’ deals with studying and documenting the problem that needs solving, whereas ‘design and implementation’ are related to the solution, I have the following problem with the term object-oriented analysis :

    Either a class model in OOA :
    1) is just an ER-based (conceptual) data model, in which case it is not a good object-oriented model at all. It would be a good description of the problem domain because ‘things’ usually don’t do much, they ‘posess’ the properties we record about them and it is the actors (human or automated) that actually manipulate them and display all behaviour. In this case, an actor (e.g. an employee) would add items to a sale and calculate the discount for each.

    Or a class model in OOA :
    2) is truly a good OO-model (thus including behaviour with regard to some basic OO principles). But then it is not analysis at all since ‘things’ aren’t really intelligent. For example, items could add themselves to a sale and automatically calculate their own discounts. But in the problem domain that is not what happens of course, so this model would not describe the problem but already some kind of altered simulation thereof (which implies it is more a design model than an analysis model).

    As I see it, a model built during OOA is either not OO (but simply a data model) or it is not really an analysis artifact.

    So what do you consider to be the difference between an object model and a plain old ER-based (conceptual) data model?

    • Alex P says:

      Hi Yanic

      I’ve checked out your product – it looks interesting but not something I would use – it’s a long time since I’ve done a sequence diagram!

      I think your ‘analysis’ is sound. I don’t see any value (others might disagree) in adding behaviour in the forms of methods to an OOA model.

      As a result, you are probably correct that there is no difference between an object model and a conceptual data model in terms of content or purpose. Obviously the notation is different.
      It all comes down to your modelling preference or experience.

      I hope this has answered your question?

      Alex

  6. Yanic says:

    If it looks like a duck, swims like a duck and quacks like a duck, then it probably is a duck.

    Your ‘business object model’ looks like a (conceptual) data model, serves the same purpose as a (conceptual) data model and is used like a (conceptual) data model.

    -> So why not call it a (conceptual) data model as people have done for 30+ years, instead of taking an illogical -and highly unlikely- detour through ‘a class model without the functionality’.

    As an aside about your diagram, I’m a bit surprised to see an analysis artifact with Hungarian notation and ‘double’ for money.

    • Alex P says:

      Yanic

      You are very clear on your terminology – my experience is that object models and data models are both used when creating a ‘conceptual’ or ‘business’ view of the problem domain. The reality (imho) is that people use both data and object models for the the same purpose of representing the static view of the problem domain.
      My selection of an object model reflects my personal preference and background in using object models instead of data models. You clearly have a very fixed view but I don’t believe it is useful for this article to be so prescriptive about what is correct.

      Regarding your comment about Hungarian notation, I’m not familiar with this term but I assume it refers to the first letter in the attribute name indicating the type of the attribute. On this point, you are entirely correct – I was somewhat lazy and took an ‘example’ from the web rather than drawing up my own. This is a reasonable example but I WILL put it on my to do list to correct and simplify the diagram.

      Thanks for the feedback – happy hear some more

    • http://www./ says:

      I told my kids we’d play after I found what I needed. Damnit.

Trackbacks

  1. […] skills, to represent requirements information in graphical forms, produce  business object models, conceptual data models, process models […]



Leave A Comment...

*