How do you design for a database platform which doesn’t require design? Should you design your data at all, or just start building?

I’d like to think I have a somewhat unique perspective on this, working at Nike where I have a front row seat to world class product design and innovation.

Perspectives vary on the importance of designing data these days. Traditional databases fundamentally force a certain level of design, to define the structure of your information before content can be inserted. But many NoSQL databases will accept whatever data format you throw at them, and you can completely change that format from one record to the next. So in theory you don’t need to have a plan for your data at all!

I strongly believe that you need to have a plan. Designing your data brings clarity. It exposes what you do and don’t know about it, and what confusion may exist about it within your team and organization. Designing data is an essential form of leadership, charting a course and testing ideas, bringing forward a clear story while being open to changing it based on new learning.

Most importantly, design is about understanding the consumer, knowing what audiences will be using the system and what they need the data to do for them. Data modeling can greatly accelerate development, improve the quality of the end product, reduce maintenance costs, and multiply the value of what has been built by establishing a common understanding of the information.

In many ways up-front data design with NoSQL databases can actually be more important than it is with traditional relational databases. For example, since many of these databases don’t join data sets, their fast-retrieval performance potential excels only if the collections you’ve created contain all or most of the information required by a given request. If you have to retrieve a large percentage of your database content in order to scan and filter it down to a relevant result set, you would have been better off writing SQL to join tables within a relational database. But as I have seen in my experience, good data design practices can lead to excellent performance.

Beyond the performance topic, NoSQL databases with flexible schema capabilities similarly require more discipline in aligning to a common information model. For example, MongoDB would not hesitate to allow you to sequentially save four records in the same collection with field names of: zipCode, zipcode, ZipCode, and postalCode, respectively. Each of these variations will be treated as a new field, with no warnings given. Everything will work great until you ask for your zipCode values back and only one document out of four has a field by that name.

The flexible schema is a great innovation for quick evolution of your data model, and yet it requires discipline to harvest the benefits without experiencing major data quality issues and other frustrations as a result.

Data modeling is essential for success, but it’s not rocket science, and with this book it is easier than ever to implement effectively. Written by an exceptional teacher of data modeling, these chapters clearly explain the process needed to navigate these new capabilities with confidence. Anyone who has taken Steve’s Data Modeling Master Class can attest to his passion for both data and teaching. In reading the manuscript, it was immediately evident to me that his gift for teaching is here in his writing every bit as much as when he presents in person. Steve carefully crafts his explanations so that even the more abstract concepts can be easily grasped and internalized. Steve’s broad consulting experience also shows through.

Seth Godin states in his book Linchpin that there is a “thrashing” process inherent in the creation of any product, meaning the brainstorming and iteration of different ideas and approaches. He writes, “Thrashing is essential. The question is: when to thrash? In the typical amateur project, all the thrashing is near the end…Professional creators thrash early.” Anyone who has found themselves at the tail end of a poorly-executed project knows all about late thrashing. Early and ongoing modeling adds tremendous value, no matter how agile your methodology.

Steve’s book is about how to work through uncertainties like a professional, so you can evolve your data models over time without devolving into chaos.

May your data models provide calm and clarity which allow your work to thrive, so that you can focus on what matters most: your team, your objectives, and your consumers.