Part of the value the business analyst provides is selecting techniques to ensure the requirements for a project are fully analyzed and understood. Data modeling can be a significant part of the project requirements to rightfully non-existent, even for a software project.
In this article, you’ll learn what data modeling techniques to consider in specific project contexts so that you can leverage your business analyst tool box in the best possible way on any given project, making you more effective and part of driving more successful project outcomes.
(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)
A Case Study in Selecting Data Modeling Techniques
This can start to get a little theoretical, so let’s start by looking at a sample project, why I chose each technique, and how they fit into the business analysis process. This particular project was a customer-facing information management system that was designed to replace a forms-based paper process.
- I chose to start with data mapping because I needed to understand how the information flowed from the paper-based forms to the existing information technology system. (This happened at the beginning of the project, as part of defining scope and understanding the current state.)
- Then I created a conceptual entity relationship diagram (ERD)Â because we needed a way to blend our new business concepts into our pre-existing database structure. (This happened in the middle of the project, as part of transitioning from requirements analysis to technical design.)
- Finally, I got into the details with a data dictionary because we were working from one data source that needed to support two separate systems. (Although I could have started the data dictionary earlier, alongside my wireframes and user stories, it was actually completed more as a wrap-up deliverable towards the end of requirements, during technical design and implementation of a future state system.)
In this particular project, I happened to use all of the techniques. However, I’ve worked on several projects throughout my career that applied only one or two of these techniques, and a few with none at all.
Different Projects Call for Different Techniques
The project you are working on will inform what techniques are appropriate. Here are some general guidelines you can use to help you decide what techniques to consider for your project.
- On a data migration project, you’d optionally start with an ERD, move on to creating current state data dictionaries for both systems (unless they already exist), and then create a future state data mapping specification to show how data moves from one system to another. If changes to either data source are required, they could be specified using a future state data dictionary.
- For a relatively small change to a pre-existing system, you might make a small update to an existing data dictionary, glossary, or ERD, but it would most likely be unnecessary to recreate all 3 of these models from scratch to represent the current state.
- For a system integration project, you might start by creating a system context diagram to map the flow of data from one system to another, move on to creating data dictionaries for each data source, and finally, if needed, create a data mapping specification. (You’d only need a data mapping if data is actually moving from one system to another, which is not always the case. More often, system integration projects, like the one mentioned in the case study above, are using a single data source.)
But again, data modeling is not required for every project. For example, a change that only impacts the user interface or flow of the application and does not actually touch the data model would not require any of these data modeling techniques.
What’s more, if you are working with a data architect or analyst, it may be that your involvement in more detailed specifications like a data dictionary is in more of an input and review capacity than a creative one.
Data Modeling Adds to Your BA Toolbox
Most business analysts think of the set of techniques they know more like a toolbox and less like a process. The techniques get swapped in and out depending on the needs of the project. Most of them can be used independently but each tool you bring out builds upon the others.
The bigger tool box you have as a business analyst, the more types of projects you’ll be able to handle successfully.
Given today’s emphasis on information technology systems, reporting, and data intensive applications, you can safely assume that you should be at least evaluating the data modeling techniques in your toolbox to see if any of them would be relevant to your project. And then you want to double check that someone with a business perspective (not technical expertise) is paying attention to them. If no one suitable comes to mind, that person is most likely to be you!
>>Learn More About Data Modeling (Free Training)
Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.
