When you reach that point of the project where your head simply hurts from how hard you are thinking, you’ve spent hours in meetings rehashing the same concepts, and yet you and your team members are not communicating effectively either about the problem or the solution, you most likely need to take a step back and confirm what each of you understands (or doesn’t).
I call this the “gnarly part” of the project and no matter what your methodology or expertise, you are likely to hit it at some point.
One technique I like to use when I sense my project team is failing to communicate about important concepts is a Business Domain Model. A domain model logically represents the business concepts to be fulfilled by the system and how they relate to one another. It should not be confused with a data diagram, with represents the actual database design or architecture. Although they may look similar, a domain diagram should use terms that are in the business domain.
(Both Business Domain Models and Data Diagrams are two of many visual models that BAs use in their work.)
Here’s an example of a domain model
This is a small section of a domain model I completed a few jobs back. It probably won’t mean much to you, because without understanding the business context and what the terms mean, domain models do not really tell you much. However, I’ve found them to be great conversation pieces, much like a coffee table book of your favorite vacation spots.
Let’s take a quick look at each element of the domain model
The boxes represent entities, or business concepts, and the lines between them explore the relationships between each concept. In this example, an RC Account can be related to zero to many VL customer profiles. This was a key concept for this product as we were leveraging a one-to-many relationship between the accounts in our legacy system and the accounts in our new system. As can be imagined, there was a lot of disagreement and discussion about this. Hence, the coffee table book effect.
Within each box, you list key data elements (in a precise data model these would be the fields in the table) that are part of the business concept. You can also identify whether each element can have multiple values.
>>Interested in Learning More?
We provide more detail about business domain models and 21 other models BAs use in the Visual Model Sample Pack. The Pack contains 22 real-world visual model samples covering everything from UML diagrams to whiteboard drawings shared from the files of a working BA. You’ll be able to more easily incorporate visuals into your requirements process and get the process moving faster.
3 thoughts on “How to Create a Business Domain Model”
Needless to say, I highly approve of this message. I draw diagrams constantly as I work with customers, using the diagrams to highlight misunderstandings and spark conversations. I find that if I handle it right, I can act as their UML tool, drawing what they say without ever having to teach them notation. After all, the shapes and connectors are all labeled using terminology from their domain. They figure it out from there. Once in a while they’ll ask me about the shapes and arrows; but more often, they simply tell me how my diagram is wrong, and how I should correct it. It’s a very productive way to get them talking.
A bit nss.
I tend to use less formal diagrams initially as they are less intimidating. Interaction diagrams and ELH descriptions of key concepts are also v. useful in flushing out inconsistencies.
The annoying thing about most diagramming techniques is that there are many assumptions that cannot easily be formally captured, but which underpin whole business processes. But that’s not such an issue for getting this type of discussion going.
I also find it useful, sometimes, (especially where there are many groups involved) to have a ‘language definition’ session where we go over common terms and eliminate overlaps. My preference is to start by making up new terms for shared, inconsistent terms so that all baggage is removed.
Good tool! There are many who are visually inclined and this reaches them. Diagrams aren’t always the panacea to problem resolution, but they always seem to spark the discussion. I’ve found that matrices sometimes have the same effect.