Creating a Business Data Diagram
I found the exercise of creating a Data Flow Diagram for a block walk/canvass so interesting that I decided to play with the same use case to create another data model, the Business Data Diagram (BDD). The BDD is one of the most important and useful models we use. It’s considered a bounding model because it helps define project scope. It’s also a powerful tool to discover requirements and plan elicitation. I’ll walk you through how I’d do that in this article.
Business Data Diagram Fundamentals
Let’s start by reviewing the basic structure of a Business Data Diagram. The most important aspect of the BDD is that it DOES NOT represent an actual database design. We’ll leave that to the data architects! A Business Data Diagram is about the conceptual data objects (the boxes) and their relationships (the lines), and it’s a great tool for talking about the data with non-technical stakeholders. The really fun part about this model is figuring out the cardinality. I usually create the boxes and lines first and then sort the cardinality, one relationship at a time.
Drafting the Business Data Diagram Model
The first draft I made of the model was fairly easy. There’s a clear hierarchical relationship from voter all the way up to the state level, and the relationships are pretty obvious. Unless a voter moves or the precincts get redrawn, these relationships are pretty durable.
But then, I wanted to add the canvass and its associated data. The canvass is a time-boxed event that has relationships with the physical concepts of voters, households, and geography. As you recall from my previous article, the canvass is often expressed as a block-walk staffed by volunteers or paid canvassers who knock on doors. It can also be a phone bank or a text bank event, but for our example we used the door-knocking use case. To make it easier to read the model, I colored the canvass-related data objects orange. Using formatting changes to convey additional information can be a very useful modeling hack.
Using the Business Data Diagram Model in Elicitation
Based on my own experience as a volunteer who has interacted with canvass data, I drafted the rest of the model, but, as is usually the case, I have questions. The questions are why we create models! Using this draft, I can plan elicitation with my subject matter experts (SME) which will not only allow me to correct and finish the model but will also turf up (pun intended) data requirements which I’ll need to document.
The questions I’d need to discuss with my SMEs are:
- Does a canvass have a relationship to county or state, or is it always associated with precincts?
- Can a turf cross precinct lines, or is it always contained within a single precinct?
- Do turfs only exist as an aspect of a canvass?
- Does a canvass have only one script, or can multiple scripts be associated with a single canvass?
- Do the voter responses during a canvass remain associated with that voter for any other user to view, or is that data only visible to someone viewing the specific canvass?
- Is the ability to create a canvass limited to certain users?
- Is the ability to view canvass data limited or can any user access them?
- How is the canvass data used, enriched, or transformed by other system users or operations?
- How long does the canvass data persist after the canvass is complete?
Of course, each of these questions could lead to other questions or to discovering additional data objects and relationships. You might not be able to explore all of these in a single meeting or email!
Next Step - Requirements!
When you’ve completed elicitation, this model should represent all of the data objects that will impact your product design/project. Next, you’ll document the requirements for Create, Read, Update, and Delete (CRUD) of these data objects. You’ll capture the business rules associated with the relationships and cardinality of the data objects. And you’ll have a solid basis for the more in-depth conversations about strategic data usage and reporting.
I always recommend that project teams create BOTH Data Flow Diagrams and Business Data Diagrams, because each shows a different, important aspect of the data to help you create a complete set of related requirements.
For a detailed discussion of all of the Visual Models we use in our projects, check out our book Visual Models for Software Requirements.
