7 Tips for Staying Relevant and Valued as a Data Modeler

You aren’t going to get any warning when your company’s first NoSQL project shows up.  It might be the result of a 19th-hole acquisition project (when C-level executives are wined and dined by a software vendor) or it might be part of a package solution that someone has purchased.  And it will need to be installed and running by tomorrow.

I recommend you check out Hadoop-related data technologies, a graph database, a key-value pair database and a document-based database.  Attend user group meetings for NoSQL technologies.  Attend a whole conference.  Read.  Watch videos.  You’ll need to understand where NoSQL technologies fit within a modern data architecture.

I have worked with more than a few data architects who have never reverse or forward engineered a database.  I’m not sure how they have survived all these years, but data architects need to have the skills to reverse engineer a database, even with package solutions.  Sure commercial software might be missing primary keys, foreign keys and all kinds of constraints and other database-hosted data quality features, but we need to know that, too.It’s not enough to know how to click NEXT, NEXT, NEXT on your data modeling tool, either.  You’ll need to understand what those hundreds of options are in that wizard.

There’s no strong reason why data models about core data about people, organizations, products, categories, addresses, contact mechanisms should vary across models, especially at the same company.  Using pattern data models can significantly reduce the time it takes to produce a correct and complete model.  Sure, tailoring may be needed, but if you are familiar with common data modeling patterns, you can free up a huge amount of time to focus on those data requirements are proprietary and unique to your business.

Understanding a pattern model can take some time; that’s why you need to start reading and studying now.

The new data types, identifier types, constraints, etc. for DBMSs is growing with every release.  As data modelers, we need to be able to understand the pros and cons for choosing those over more traditional features.  Take formal training if you have to.  Attend user group meetings.  Get your DBAs and developers to lead some brown bag lunches.  Read online tutorials.

Nothing says “out of touch” like having to ask what something means in a design when that feature has been around for five years.  It gets worse if you get caught specifying a deprecated approach to a design.

Whether or not you will be following an Agile approach, modern development projects need to have faster and shorter iterations.  If it takes 3 days to publish and share your data models, that’s too long.  Modeling tool automation and documentation features should be your primary method for producing the artifacts related to data models.

If these tips sound a bit more physical than you are used to, they are.  Yes, we still need to produce beautiful conceptual and logical data models, but our relevance is also being measured on how well we are able to provide business solutions.  More times than not, that means being able to effectively contribute to the designing and building of those solutions.Spending just 15 minutes a day working your way through this list will make a huge difference in ensuring your data relevance on future projects.  Your project teams will find you more valuable and be happier with your contributions.