Gorilla vs. Guerilla Modelling

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 modellers, 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 modelling – they’d never understand it.”
2. Curiosity: “How on earth did you convince them to attend a data modelling session?”

Alec Sharp, Clariteq Systems Consulting Ltd, asharp@clariteq.com

Alec will be presenting the following courses in London next month: Business-Oriented Data Modelling 24-25 October 2016; Advanced Data Modelling: Communication, Consistency, and Complexity 26-28 October 2016; Working with Business Processes: Discovery, Assessment, Mapping, Analysis and Design Alec Sharp, 20-21 October 2016

These responses lead us to some important principles:

1. The participants didn’t know they were data modelling, 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 modelling session because that’s not what it was; usually, I’ll be slyly introducing data modelling within the context of a business planning, process improvement, or requirements gathering session.

This is the difference between what I call gorilla modelling and guerilla modelling. 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 modelling 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 modelling.

If you’d like to become a “guerilla modeller,” which is especially useful in an Agile environment, here are three things to keep in mind.

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

Change begins within. Changing how others perceive data modelling (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 organisation chart, you can describe the things of interest to a business with a basic conceptual data model, understandable to everyone without any special training. Practice what I call “The Data Modelling Turing Test.” In the original Turing Test (as proposed by Alan Turing) a computer could be said to display artificial intelligence if a human interacting with it through some device or interface couldn’t tell whether they were dealing with a computer or a human. In my modified version, a person hidden behind a curtain walks through a data model, speaking entirely in “human language,” and a listener would think “that’s a pretty clear description of a business” and have no idea a data model was being presented. For instance, “Our Customers operate one or more Facilities, typically located at specific Mileboards along one of our Lines…”

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

Around 30 years ago, I was starting a data modelling session with my usual “friendly lecture” on data modelling. 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 modelling 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 modelling courses dive right into normalisation as if that were the central issue. Unbelievably, I’ve seen university courses where normalisation 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 modelling (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. Similarly, avoid the temptation many experienced modellers fall victim to – “premature generalisation.” Yes, I know “Employee” and “Customer” and “Supplier” and “Dependent” will all eventually be roles played by the generalised “Party” (Person or Organisation) but if you do it too soon, you’ll lose the uninitiated. And please, whatever you do, don’t get hung up on details like optionality or especially primary keys – those can wait until much later.

We’ll look at all of these in future IRMUK articles, 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 modeller. My next article will detail recent examples of “guerilla data modelling” helping out on initiatives like business process change and organisational restructuring.

Please feel free to contact us with questions, comments, and suggestions for future articles.

This column was originally written as a post in the blog series “CA Erwin Expert Blogs,” sponsored, of course, by ERwin. The series is no longer available online.

Alec Sharp has managed his consulting and education business, Clariteq Systems Consulting Ltd., for over 35 years. Serving clients from Ireland to India, and Washington to Wellington, Alec’s expertise includes facilitation, strategy development, business analysis, business process change, and, of course, data management. In addition to an active consulting practice that keeps him up-to-date on real world issues, he conducts top-rated workshops and conference presentations on these topics globally, typically on four or five continents a year. Alec is the author of “Workflow Modeling, second edition” (Artech House, 2009) which is widely used as a consulting guide and MBA text, and is a best-seller in the Business Process Management field with a “5 star” Amazon.com rating. He was also the sole recipient of DAMA’s 2010 Professional Achievement Award, a global award for contributions to the Data Management field.

Copyright Alec Sharp, Clariteq Systems Consulting Ltd