by Karen Lopez
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.
2. Learn how to correctly reverse engineer application databases
3. Get experience data modeling for integration projects
Not all data modeling results in a brand new database built from scratch. One of the most common reasons I've been doing modeling is for building canonical models for integration projects. These are often implemented as XML schemas, but I start with a logical data model of requirements using very similar techniques as I do for a database design project.
4. Learn a pattern or universal data model
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.
5. Learn more features of your data modeling tool
Like many productivity tools, data modeling tools have evolved a great deal over the last few years. We architects benefit from a significant number of mature features in our tools. And like office productivity users, many of us use only 10-25% of those features. Automation is a key part of many of the leading tools, yet some modelers are reluctant to learn new coding and scripting skills needed to master them. You should. The payoff for productivity can be significant after a short learning curve.
6. Learn about the new features of your target DBMSs
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.