by Alec Sharp
Data modeling is fairly mature tool that has been around for a long time, with no major changes in the past few decades. But nonetheless, many data modelers act as their own worst enemy by unwittingly discouraging people from getting involved in it. One of the most common ways data modelers do this is by simply talking too much about data. They describe data modeling in ways that are too complex for a business audience. This is a widespread problem, for both new and experienced data modelers.
It will be much easier to gather support for data modeling if you refrain from actually calling it “data modeling.” Rather than speaking in language that a business cannot comprehend, most data modelers will have more success by data modeling stealthily, rather than overtly.
The most helpful ways to gain more support for data modeling are to:
- Avoid lecturing to clients about data modeling. It creates a barrier between you and them which is difficult to tear down once it has been created.
- Adhere to the graphic conventions of the industry when creating your model. Information is rendered in graphic form for a reason – to simplify it for the viewer.
- Repeat yourself. Use scripts. Be consistent, be sure that you are doing the same thing the same way continuously.
- Use data to show what they have, or what they don’t have, and what is problematic about it. This is a very useful way to gain support.
Businesses are now more diverse, more fluid with acquisitions and mergers, and more geographic with distribution than ever before – all of which necessitates a common language. This is not so we can immediately build a database, but rather because all businesses revolve around things. Processes act on things, applications revolve around things, and most importantly, businesses want information about things. It can be more useful to start thinking of data-modeling as thing-modeling. Rather than worrying about data, think in terms of understanding what each client’s business actually deals with.
I used to begin every data modeling session with what I thought was a fascinating lecture on data modeling. Well, one time someone pretty much started yelling at me in a session when I did that. This fellow, he said, “You know what, we are so sick of you IT guys coming down and trying to teach us your language. We wish just once you’d come closer to ours.”
Instead of beginning with an incomprehensible lecture, interview different functional area representatives about what they do – activities, goals, and objectives. Essentially, ask them about their needs and their wants. Take copious notes, say, “Slow down, I didn’t get that.” This is a great way to build a relationship with a client. Later, take the terms they’ve used and write them down on giant Post-It notes. Afterwards, in a process session, ask the client to clarify all of these terms, just to avoid any potential misunderstandings in the future. On pre-laid out flip charts, ask the client to divide terms into three basic categories: Things, Facts, or Other Stuff.
It’s very rare that any business audience needs a definition of a “thing.” So this process levels the playing field, and prevents the inevitable miscommunication that happens when a data modeler opens a meeting with a jargon-heavy lecture. Once you’ve learned more about the business area, draw five boxes. If you can help a group reduce their area of interest to five boxes, and simply say, “Tell me about your quotation,” you’ll learn so much more than you ever would by asking, “What are your data requirements?”
As a consultant, I’m astounded by the number of data models I see which absolutely defy graphic conventions, catering to a very technically strong audience. Laying out the model according to dependency is one of the most important conventions of the process. Kernel entities should be at the top, characteristics below, associative between and below, and reference like so. In the business world, a top-down layout wins every time. You may have a beautiful model, but its functionality is most important. It should assist to abstract things, to attenuate some information while accentuating others, and it should always use visual cues consistently.
Consistency is key not only in the drawing of your data modeling, but also in the way you speak to clients. Use scripts. For instance, when trying to get a group of people to define an entity, don’t just ask them for a definition. Instead, look for the anomalies at the outset. Ask the group to tell you something about the entity which they believe is defining, yet know would surprise someone else. This one is really important in practice because it engages people, heightening their level of interest in what you’re doing – which will yield better results for you.
Build your own scripts. Anytime you’re adding a characteristic entity, think about the questions that you should always ask when you create a new one. It might be something as simple as, “Well, can the parent ever exist without one of these,” if you wanted to talk optionality. Or an associate entity – what’s a good question to ask when you create a new associative entity? What do you need to know about this thing? What’s important about this? Or, can the same two parents have more that one of these? If you ask these questions you always uncover additional requirements that you wouldn’t have expected or have gotten otherwise.
The final point is to show your clients what they have. A lot of data modeling doesn’t start with a blank white board; rather, it involves helping a business deal with a package they bought and now wish they didn’t, or salvaging the legacy that no one understands, or simply breaking down the fundamental facts of their situation to them. Any kind of group could need this help; I was once approached by a Human Resources representative of one of the world’s biggest companies to help them figure out a regrettable package they purchased. In these situations, you find the physical data somehow and express it in the usual terms, elevate it to a higher level of being and simplify it into a conceptual overview or business plan.
Beginning by looking at dependency will allow you to see the most important stuff first. It’s the easiest first step in building a presentation for a business audience which allows them to clearly see what they actually own. Different things can happen. They might be unhappy, or they might think that’s wonderful, so different possibilities. Anything from jubilation or glum acceptance to shock and awe or sorrow. And I’ve gone through this and the outcomes have been anything from, “Oh my God this is so much better than we realized, to “No wonder we’re in trouble with the Federal Government.” Reactions vary hugely.
A client once brought me into help them deal with a problematic system they purchased, Super App. 1. They spent ten times the purchase price of the application to modify it because the looked at the features rather than the underlying data structure. I interviewed people to find out what they hated about the package, and based on their answers I developed a conceptual model. I got two inches of DDL, went through tracing foreign keys until I had a data model, and then I simplified it for a business audience. I presented it to them by saying, “This is how I believe you see the world.” I talked through the busiest terms without ever referring to the drawing as a “data model.” I got a lot of mileage out of the term “world view.” And after I’d gone through that, the training manager said, “That’s the clearest description of our business I’ve ever seen. Could we please have that for our orientation material?” Then I started drawing how super apps sees the world. I didn’t have to talk about entities and semantically overload or anything like that. They could just see it as plain as could be. Simplifying a company’s world view and presenting it to them objectively will clarify any potential conflicts they might have with an application, another business, or other corporation.
ABOUT THE AUTHOR
Alec Sharp, Senior Consultant, Clariteq Systems Consulting
Alec Sharp has managed his consulting and education business, Clariteq Systems Consulting Ltd., for close to 30 years. Serving clients from Ireland to India, and Washington to Wellington, Alec’s expertise includes facilitation, business analysis, business process improvement, and, of course, data management. In addition to his consulting practice, he conducts top-rated workshops and conference presentations on these topics globally. Alec is the author of “Workflow Modeling, second edition” (Artech House, 2008) which is widely used as a consulting guide and university text, and is a best-seller in the field.
