Pragmatic Data: Another Good Reason to Model Your Data

At some point in your career you have probably heard the words, “why do I need a data modeler?” Perhaps it was in response to a budget estimate. Maybe someone just didn’t understand what data modeling meant for their project. Or you yourself might have been the one questioning the time and expense of formal data modeling.

When faced with this resistance, we dig out the usual justifications—methodology, exposition, design—with mixed results. “It’s in the SDLC!” the Project Manager says. Methodologies do create solid frameworks and help keep project artifacts consistent, but formal artifacts can look suspiciously like overhead in an extreme-programming, minimum-viable-product, startup style project. Facilitated modeling can bring deeper understanding of the problem space (“The spec is in the data!”¹), but for experienced teams with strong product owners (in the Scrum sense) the extra analysis can seem like a waste of scarce resources. As Graeme Simsion pointed out back in 1996, data modeling is also fundamentally a design exercise², and can serve the basis for physical databases, object models, service and API schemas. But developers and BAs design, too, and lightweight artifacts (and heavier ones, like whiteboards) are sometimes held up as a reason “we don’t need modelers.”

Don’t get me wrong—methodology, exposition, and design are all great reasons to create data models. They always have been and always will be. But they’re not the only reasons. There is a different angle that data modelers should consider when we make our case: data modeling (good data modeling, that is) can shake things up.

I often create data models for organizations that have limited experience with data modeling. At the beginning of these engagements, a little bit of initial resistance is fairly common. But even when it’s been difficult to get past “why do I need a modeler?” to find time with the right people, there ends up being a moment of “wow” as the conceptual models first come together. I hear things like “we’ve never been able to agree on language like that before,” and “I don’t think I’ve ever understood our business this well.” Why is that? It’s because we, as data modelers, think a little bit differently about the world.

What is it that works in our approach, in that different way of absorbing and articulating the way the world is? What works is simply that it is different.

This has to be one of my favorite journal article titles, from Elsevier’s journal, Cognition³:

It’s also one of the most memorable. The main reason that this title is memorable is, in fact, exactly the subject of the paper itself. Diemand-Yauman, Oppenheimer, and Vaughan discovered that the more challenging they made a task, the deeper the necessary processing became, and the better the participants retained what they learned in the process.

Applying a little bit of methodology to the madness doesn’t seem to hurt, either. In the early 1970’s, artist Peter Schmidt and musician Brian Eno developed a deck of about 100 cards called “Oblique Strategies,” and harnessed the same effect to “help artists (particularly musicians) break creative blocks by encouraging lateral thinking.” ⁴ The cards contain suggestions like “Only a part, not the whole,” “Honour thy error as a hidden intention,” and “Use unqualified people,”⁵ and were designed to be pulled out at random to break up a stalled recording session. In an instruction that would seem familiar to anyone who’s led data modeling sessions for the untrained, one version declares: “…the card is trusted even if its appropriateness is quite unclear.”⁶

Done well, data modeling brings this same constructive disruption to the application development process. The whole process serves a somewhat hidden, secondary purpose beyond the methodology, exposition and design. We often begin by disturbing the basic setting of an analysis meeting. Rather than setting up a web conference or sitting around a conference table, we modelers often stand in front of a room with sticky notes or dry erase markers. This change in position alters the dynamics of the room, setting up a more constructive, active process right from the beginning.

We change the language, too. We don’t simply draw literal pictures of a subject, but instead abstract it to our own language of boxes and lines – unfamiliar to most in the room, even developers with their own box-and-line dialects. We begin the conversation with simple terms familiar to the rest of the participants, say, “client,” “invoice,” and “account.” Then we proceed to not only demonstrate how unclear those terms really are (“what is a client, exactly?”), but also define whole new vocabularies to describe those concepts (“party,” anyone?) and ways to relate them to each other. We push our analysis into the dark corners of obscure processes and shine light on the assumptions implicit in the vocabulary of business. There are technical benefits, of course. We expose and learn more about the subject we’re analyzing. We design structures to store and integrate the needed data. And we create artifacts to guide current and future work. Beyond those benefits though—and perhaps even more valuable—the data modeler’s unfamiliar terminology, interactive process and abstract visual metaphors make collaborators just a little bit uncomfortable, but in a good way, just like Brian Eno’s cards in the recording studio.

Data modelers bring unique value beyond just analysis or design. A skilled professional can elicit requirements and create diagrams, but there are limits to what a single person can discover or infer. A good data modeler can go beyond simple elicitation and help generate new perspectives. The challenges created by the data modeling process help encourage creative thinking about current problems. Our novel visual metaphor, new uses for old terms, and close examination of real-world business artifacts force a different perspective. And that shift in perspective both encourages innovation and helps ensure that the teams working to model their data retain all that they learn from each other in the process.

Sure, data modeling is a valuable process to figure out a domain of interest, design databases and software, and create documentation. Those are certainly important things to bring to an IT project. But as development methodologies shift, and business leaders change their thinking about systems architecture and design, it doesn’t hurt to look a little further. Data modelers bring a little chaos to the party. And that’s a great thing for the project, for everyone in the room, and for the whole business.

(If you’d like to hear more ways that messy problems can drive creativity, check out Tim Harford’s TED talk here)

1^ Barrette, Jordan MIOSoft Blog “Data First, Part 2,” March 2015, https://blog.miosoft.com/2015/03/data-first-part-2-the-spec-is-in-the-data/