In one of my previous posts, I discussed whether data modeling is art or science, and I concluded that, unfortunately, the current state of affairs is that it’s closer to art than to science, whereas I would like to see the opposite. And I think that the same applies to process modeling.

Back in 1994, I learned about a methodology that managed to transition data modeling from art to science. As a result, I have become much more effective at creating successful data models. The root cause of this methodology is that it is founded on three basic principles that I have since embraced for everything I do.

The Jargon Principle

The first of the principles I learned in 1994 is called “The Jargon Principle”. I don’t recall the exact wording, but here’s how I would paraphrase it:

“For all communication that takes place between analyst and domain expert, the analyst will use the jargon of the domain expert instead of forcing the domain expert to use the jargon of the analyst.”

So, what does this mean and how to apply this principle?

Jargon is great …

For most people, the first association that comes with the word “jargon” is the nutty professor scribbling tons of unintelligible symbols on the chalkboard, or the highly qualified engineer that no one understands because he assumes that everyone not only knows exactly what an ACMF engine is, but is also extremely interested in discussing its details. And though these are definitely fine examples of jargon, I am using the term in a much broader sense here.

The jargon that the Jargon Principle references applies to all forms of communication, be it language (spoken or written words), symbolic (numbers, diagrams, tables, etc), or any other form. As soon as this communication uses elements that are familiar to people in a certain group but not (or less) familiar to people outside that group, I consider it to be jargon.

Every group and every profession has its own jargon. And for good reason. When I am in the United States to attend a conference (like, recently, the PASS Summit 2011), I sometimes switch the television to a sports channel. And then I invariably get to see people playing the game the Americans call football (even though they primarily hold the ball in their hands), and I then hear the commentator mention that a player is “three for seven”. I have no idea what that means. But I am sure it makes sense to all who regularly watch these games, and it would become very boring and longwinded if the presenter had to explain this bit of jargon every time he uses it.

And just think how hard our own job would become if you could not say to your colleague that you believe that discount should be an attribute of the Sale entity instead of a relationship. Or if you could not use Entity-Relationship Diagrams to lay out the design of a new application and discuss it with your peers. Those are exactly the situations that jargon is intended for, because it helps you communicate more efficiently and more clearly with your co-workers – the shared jargon ensures rapid communications without misunderstandings that can could result from having to describe everything in “normal” English.

… except when it isn’t.

The examples above that illustrate the greatness of jargon all have one common factor, and that is that in these examples, the jargon was used to facilitate communications between people that share knowledge of the same jargon – except the first example, that left me sitting bewildered in front of the television set, wondering what the hey the commenter meant when telling me that a player was “three for seven”.

When you, in your job role as a data modeler or process modeler, step outside the safety of your office where your coworkers are to discuss the next application to build with the domain expert, you are talking with someone who does not know the same jargon you do. If you have to create the data model for the local candy store and you ask the owner if she agrees that discount should be an attribute of the Sale entity, your only answer will probably the “thud” of her jaw hitting the floor. If she answers anything else, she either is an expert in the field of data modeling herself, in which case she doesn’t need you, or she is afraid she’ll look dumb if she admits that your words are Greek to her and gives random replies in an attempt to mask her perceived lack of knowledge. Whereas in fact, you are the dumb person, because you asked a question in a jargon that is unfamiliar to the domain expert, setting her, yourself, and the entire project up for failure.

What’s the alternative?

I hope my examples above have convinced you that you should not ever use your own jargon, the jargon of the data or process modeler, when talking to domain experts. And since not talking to them is not an option, you are now left with only two options. The first is to avoid the use of any jargon. That might look like a viable option, but it has problems. How do you even know if a word is jargon or not? When I use the word “person”, I usually think about a human being. But for a lawyer, a person is a legal entity. He will use the word in that context without even realizing he’s using jargon. And I can’t help it, because (a) I may not even be aware that he is using jargon, and (b) that would still mean forcing the domain expert to talk my (now jargon-free) language, a practice I don’t like.

And that leaves only one option – modelers should use the domain expert’s jargon when talking to him or her. That’s the Jargon Principle.

How?

Stating a principle is easy, living up to it can be hard. But if I want to take myself seriously, if I want to ensure that I base my models on trustworthy information, I have to force myself to live up to this principle. Any other method of communicating with the domain expert simply carries too much risk of failure.

And I’m not the only one who believes so. If you check job adverts for data modeling jobs, or even for analyst and developer positions, you’ll almost always see the requirement that candidates have to have several years experience in the companies’ line of business. That is not because oil producers use different modeling languages or different dialects of T-SQL and C# than hospitals. It’s because people with several years in a line of business generally have picked up enough of the relevant jargon to be able to communicate efficiently with the domain experts. However, this interpretation of the Jargon Principle is both limiting (for the modeler) and dangerous (for the business).

The “limiting” aspect is quite obvious. If your first job as modeler happens to be with a bank and you decide to move on after six years, you’ll probably have a good chance to be hired as data modeler for another bank – but not in any other industry. You might as well update the job title on your resume from “data modeler” to “data modeler in the banking industry”, for that is what you’ll be doing the rest of your working life. Unless you are willing to slip back into the junior role again, and to accept the corresponding pay cut.

The “dangerous” aspect is less obvious. So let’s start with a quick show of hands. Everyone who has ever witnessed a data professional, be it a modeler, an analyst, a developer, or whatever other function, say something like “they don’t specify this configuration option, but I’ll put it in anyway, just in case”, or “rip this out? Hmmm, I’ll just comment it, they’ll surely want it back within a few months” (or encountered such commented code in decades old programs), or even “nah, that spec is incorrect, I’ll do it another way”, raise your hands. Yup, thought so. Now raise your other hand if the person who said that just happened to be you. I’m willing to bet that at least 80% of you are now in the universal “I surrender” position.

This comes from the fact that several years of experience in an industry will teach you way more than just the jargon. You’ll find that your knowledge starts to match that of the domain expert, or even exceed it if the domain expert has less experience than you do. And if the domain expert says something that does not match your experience and your notions of how the business works, you may even be tempted to disregard the words of the domain expert and push on with the model that you think is the more correct one. And you might even be correct. But you might be wrong as well, and that’s where the danger lies. In a well-organized company, statements made by the domain experts are under scrutiny, because they make up the specs of the system. Deviations from those specs by a smart-ass modeler (or developer) have a much higher chance to go unnoticed until it’s too late.

Bottom line

I believe the Jargon Principle to be of utmost importance when doing data or process modeling. In the current state of affairs in our profession (that of data professionals), this unfortunately means that one needs sufficient experience in the industry of the domain expert to pick up his jargon. The down sides and risks of this have to be accepted as the lesser of all evils.

However, I also believe that there must be a better way. I believe that it’s possible for a data modeler to speak the domain expert’s jargon without first having to master that jargon, by simply following rules that specify exactly what questions to ask and how to phrase them. How these rules work exactly is out of scope for this post, but those who own the first SQL Server MVP Deep Dives book (and those who don’t should buy it now, along with the second SQL Server MVP Deep Dives book – all author royalties go to charity, so you get two exceptional books and help children in need along the way) can read my chapter on finding functional dependencies (a small but important part of the work of a data modeler) to get some general idea how this communication method works.