Language is to Thought, as Modelling is to Design

I'm a touch obsessive about using modelling correctly and consistently, whether it's ER, BPMN, Use Cases, or sequence diagrams it's worth doing rigorously to the standard.

Sloppy modelling comes out of, and causes slopping thinking. I'll even take it a step further - modelling is thinking.

If we use the metaphor of language this is obvious to us. Someone who doesn't have the words to describe something can have a flash of an idea, but he will struggle not only to describe the idea to someone else - he will also struggle to tease out all the details and implications of the idea.

An economist has a lot of language to describe what is happening along a supply and demand curve. Having this language allows him to communicate with colleagues easily - but also to think rationally and easily about what is happening inside a market. He has all the mental shorthand readily available.

Similarly a process modeler has a lot of boxes and arrows to describe what's happening in a process and how two people may collaborate. So not only can he communicate with the workflow developer, but he has the vocabulary to do it.

Case in point - I've noticed that has BPMN's support for messaging has improved people are thinking more and more about how processes communicate. It's not that it didn't happen before, but now we have the language to describe it.

In both cases the purpose of the language is that you shouldn't even think about it anymore. You shouldn't see use cases, process modelings, or ER diagrams; you should see interactions, collaboration, and entities. It's only when people model badly that you have to stop to think about models.

A word of warning though - languages box you in. Using the BPMN view may blind you to something that's more obvious in the text-narrative view. The Class diagram view may blind you to something obvious in the ER view. The Keynesian language of economics may blind you to traps of govt inefficiency blindingly obvious if you are speaking like Milton Friedman.

A lot of people assume that you can simplify language as long as you get across the basic idea, and this is true up to a point. But if you don't know the language, you'll never know what you've left out.

This is a very long winded response to a conversation I had at work yesterday about what sort of training we should send budding process-improvement champions on. Someone suggested a course that focused on strategies and process patterns was best, I held that focusing on teaching them to talk about processes was all that was necessary. If they've bright it's all you need, and if they're not it's not going to work anyway.