If you come from a technical background, you might be wondering if you can skip data modeling and go right to designing and implementing the database. While you could theoretically bypass any of the data modeling techniques, there are still very good reasons for using them.
In this article, we’ll look at how data models are easier to change than databases, why data models are easier to review than database designs, and consider how data modeling principles will help you succeed in a wider range of software projects.
(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)
#1 – Data Models are Easier to Change than Databases
A spreadsheet is easy to change.
- You don’t need this field? Let me delete it.
- This isn’t a text field? Let me put a new attribute type in that column.
- You need to split these fields apart? Let me add that in.
In a database that’s already been designed and perhaps built, you may be a little more reticent to make these types of changes, meaning that you unconsciously push back on what the business wants just because it will be more work for you.
Yes, your technical skills can help you move into more of a business analyst type of role, but it’s imperative that you also learn to appreciate business needs, wants, and requirements as part of the analysis process.
While it’s conceivable that you are a super hero and willing to do whatever it takes to meet the business needs, no matter how much work it means for you, let’s look at another reason to work on data modeling before database design – it’ll save you a bit of time too.
#2 – Data Models Are Easier to Review than Database Designs
While you can output versions of just about any entity relationship diagram or data dictionary from your database development, these models aren’t necessarily ready for review by the business. They tend to contain an overwhelming about of information for a business stakeholder – a lot of information the business doesn’t care about.
Business analysts create meaningful abstractions that help business stakeholders make decisions. These are easier to review and provide feedback on. While you could simplify automated output to create such an abstraction, it’s likely to be more work than just creating the abstraction in the first place.
Finally, if you are looking at a long-term business analyst career, there is one more reason to focus on data modeling over design.
#3 – Data Models Will Help You Succeed On More Projects
While on today’s project you might understand the database technology in place in your organization, perhaps because you’ve built it, tested it, or maintained it, as you grow your business analysis career, your technical skills will fade into the background.
Let me give you an example. You don’t hear me talk much about the data querying I’ve done because I only ever learned to use a proprietary search engine syntax called CCL that has since been replaced at the only organization in which it was ever used. You also don’t hear me talk about the programming I learned, because it’s limited to a PASCAL class in high school.
These are extreme examples because I left my pursuit of technical skills behind long, long ago. But picture yourself 10, 15, 20 years in the future. If you continue to focus on your business analysis skills, any one of the following situations could be true:
- You’ll be in an organization that won’t let you have access to the physical database.
- You’ll be working on a project using database tools you are unfamiliar with.
- You’ll find yourself without the time to dig into the deeper design details of putting the database together.
In any one of these situations, you’ll still need to communicate data requirements, you just won’t be able to do so using your typical technical tools. And you’ll be glad you learned how to use data modeling techniques from a business analyst’s perspective.
>>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.