Gorilla vs. Guerilla Modeling

Thanks for visiting my new blog on data modeling here at ERwin.com. I’ll be looking at two sides of data modeling:

1. “Pure” data modeling topics in which we’ll cover specific situations and the ways in which they can be modeled. For example, watch for a post soon on “Generalization and recursion – why they go hand-in-hand.”
2. The process of data modeling, with emphasis on the social and communication aspects. I’ll explore a favorite theme – making data modeling accessible to “mere mortals” and engaging them in the process.

With that introduction, let’s dive into this month’s topic, which is an example of the second kind of post.

Gorilla vs. Guerilla Modeling

I often run sessions at which a range of people, from individual contributors and subject matter experts, through to senior managers and even CxO-level executives (CEO, CFO, …) eagerly and constructively participate in the development of a data model. When I describe this to other data modelers, there are two common reactions from people who haven’t had the same experience:

1. Disbelief: “You can’t have business people involved in data modeling – they’d never understand it.”
2. Curiosity: “How on earth did you convince them to attend a data modeling session?”

These responses lead us to some important principles:

1. The participants didn’t know they were data modeling, because I didn’t tell them; in fact, I probably didn’t even use the term.
2. I didn’t have to convince them to attend a modeling session because that’s not what it was; usually, I’ll be slyly introducing data modeling within the context of a business planning, process improvement, or requirements gathering session.

This is the difference between what I call gorilla modeling and guerilla modeling. In the former, you beat people over the head about the technique, the terminology, the nomenclature, and how important it all is. In the latter, you infiltrate territory and involve people in data modeling by stealth, without them necessarily knowing that’s what’s happening. The reaction is usually so positive that I get asked back for more, at which time I might start to introduce some of the terms and concepts that make up data modeling.

If you’d like to become a “guerilla modeler,” which is especially useful in an Agile environment, here are three things to keep in mind. Each of these will be covered in more detail in future posts.

1) Reset your mindset – data modeling and database design are NOT the same thing.

Change begins within. Changing how others perceive data modeling (fear, confusion, disinterest, …) might require that you change how you perceive it. I believe that a data model is essentially a description of a business. Lock in on that phrase. Just as you can describe the work of a business with a simple swimlane diagram, or the structure of a business with an organization chart, you can describe the things of interest to a business with a basic conceptual data model, understandable to everyone without any special training.

2) Don’t talk about “data modeling” – to the uninitiated, it really doesn’t sound that interesting.

Around 25 years ago, I was starting a data modeling session with my usual “friendly lecture” on data modeling. Suddenly, one of the rough and tumble engineers at this railway blurted out “Jeez, you IT guys annoy me.” The actual language was much more colorful, but you get the point. He continued “You guys are always coming down and trying to teach us your language – entities, relationships, blah, blah, blah. Just once, I wish you’d come down and try to learn our language.” I didn’t have a good answer, so I ditched my presentation, took his advice, and asked them what terms were unique to the language of the Track and Structures group at the railway. There were plenty – close to a hundred – and so began a very productive modeling session. Since then, I’ve never started with “the lecture.”

3) Avoid the urge to normalize – it’s necessary later, but an impediment early on.

Too many data modeling courses dive right into normalization as if that were the central issue. Unbelievably, I’ve seen university courses where normalization is introduced in the very first lecture. No wonder so many people new to the field believe “if it isn’t normalized, it isn’t a data model.” The initial focus during data modeling (whether you call it that or not!) is illustrated with questions like “What are the things you care about? What do you and others call them? What are the anomalies and points of confusion?  What do you want to know about these things?” Practice getting comfortable drawing simple models that include plenty of M:M relationships, embedded reference data, and compound, multi-valued attributes like “Current/Previous Pricing Agreements.” You might have to gnash your teeth at first (I did!) but it will help your business partners get involved. And please, whatever you do, don’t get hung up on details like optionality or primary keys – those can wait until much later.

All of these will be explored in future blog posts, along with other topics in the same vein such as how to speak the language of the business and avoid “data speak,” how an “as-is” data model can be a real eye-opener, and what it means to practice empathy as a data modeler. It won’t all be the soft stuff, though – we’ll get into some tough modeling issues, too. I hope you’ll be back for more. Please feel free to contact me with questions, comments, and suggestions for future posts.

If you’ll be in San Francisco for Enterprise Data World 2010, March 14 – 18, I’ll see you there. Click here to see how you can get a $100 discount on your registration for being part of the ERwin Community. I’ve been added to the program and will be speaking Wednesday afternoon on “Getting Traction for Data Modeling – Winning Over the Masses” which explores some of the themes from this post.