One of the most common difficulties mapping adepts report is the lack of confidence in component identification. Very often, Simon’s statements ‘All maps are wrong, some are useful’ and ‘practice, practice, practice’ are not enough, especially if you are learning on your own, using publicly available resources.
This post is essentially my attempt where I try to dump and organise everything I have learned so far about the component identification process, and I do hope some of you will find it useful, at least a bit.
This post is a CC-BY-SA wiki page. Feel free to edit, use it or include it into anything you wish. Language, vocabulary and grammar corrections are welcome, too.If you need to discuss something, you may use Map Camp Slack Channel.
Look at the picture above. What components can you identify (and how many of them)? Most of you will probably say - 5 chairs, 2 tables, 2 bottles, etc. That is a natural approach, as we, humans, tend to use physical borders to identify components, even if there is no borders in the first place.
The picture below shows how our expectations shape what components can we see. While the white triangle is not drawn, you have no problems with finding it and pointing out the triangle boundaries.
Humans recognise physical borders even there where there is no objective reasons to do so. Image licenced under CC-BY-SA, original work available here
Now, if we get back to the picture #1, our expectations plays a vital role in how we do identify those components, because we can quite easily say that on the picture we can see:
- dining furniture for two couples
- an arrangement of furniture in a coffee shop
- a large number of colorful pixels
The latter might be surprising, and sound smart-assy, but it proves the point that the purpose of our analysis determines which components are important for us. Two persons looking at a given context with different goals will identify different components, as what is meaningful in one situation, might not be meaningful in other.
Certain freedom in component identification means that no approach is wrong. You can continue as you please, and the only criterium becomes “Is it useful?”, which can be translated as “Does it allow you to solve your problem?”. It does, if you have captured all the important components, and you know you have done so if:
- you have presented your thinking to domain experts, and they agree with you that your thinking is correct
- it allows you to predict what will happen in your environment
Naturally, checking with industry experts is usually cheaper than testing a model in reality, so that should be your preferred approach. The caveat here is that each first attempt to identify components results a graphical representation of what you think about the problem, and not in a magic insight in how things work. Which basically means that in order to “properly” identify components, you should:
- Do the initial work.
- Investigate all the assumptions.
- Consult with others.
- Test with reality.
And, probably, you will find out that at each step there is a refinement to be done, or you may have to start from scratch again. The message here would be:
Do not try to be right from the very beginning. The journey and discovery process matters more than the output.
If I say “snow”, you probably will think about this white thing that falls down from the sky in the winter. I will assume that you understand “snow” in the same way as I do, albeit we have different experiences, feelings and images in mind related to that concept.
The issue here is that “the snow” is just a symbol, and it is no different from “fall down from the sky”. The latter is an abstract symbol that carries a message (experience) we can relate our own observations to.
“The map is not the territory” means actually that the model we assemble out of components is exactly just a model. Symbols do not reflect the true nature of the reality, so it is always an approximation. Simon calls this a property of the language.
Recent discoveries in neuroscience show that we use the same part of the brain to navigate in our environment and to think; we store thoughts and experiences as if they were physical objects (internal map), so the hypothesis is that our thinking process is in fact a navigation exercise between everything we have experienced.
The reason why I am mentioning this is that to build a useful model, you have to use different perspectives (set of experiences) in hope you will get a model closer to the reality.
Also, uncertain, abstract components do not have clear borders. Look for example at the history of science. At some time, computer science was a part of math. Earlier, there was no geography, biology and other fields, just philosophy.
That shows that, sometimes, symbols have very undefined meaning attached to them, and it takes time, and effort to make the meaning more precise - sometimes even industry experts do not know what is a given thing, and often, naming it brings it to life.
I just cannot stress it enough - if you name an experience, or a set of your experiences, you create a component. If others will find your name useful, it will spread, and over time, the name will become a mental shortcut to the experiences.
One more thing to remember is that once you name a thing, you stop analysing the experiences to reduce cognitive effort. You substitute a set of complicated relations with a symbol, which allows for cutting-off analysis at some points.
When you do your analysis, it is important to be aware of this thing. Each concept you use, each component you identify, is a potential end of the analysis. But you might be wanting to dig in into component specifics, as there might be some important things for you there. So choosing the cut-off points should be a very conscious process (if not the most conscious one in the whole process).
Forms of capital
Understanding how symbols work allows us to identify non-physical components with greater ease. If you can name a set of experiences (or data, or practices), you form a component.
In business, you can use money to acquire any component (you exchange money for knowledge/data/practices/etc), or in other words, you buy things. The reverse process is not always possible - while you can easily buy things, selling your components might be difficult. Some knowledge (or experience) is quite difficult to monetise, especially if it is less efficient than alternatives.
That insight is a basis for some form of inertia analysis - the conversion money-asset-money is not always as easy as traditional accounting methods would say.
Therefore, a distilled version of all I have written above would be:
- Start with the purpose. Purpose determines what is important and what is not. Suitability for purpose determines the quality of your analysis. There is no objective, context-free quality measurement of your analysis.
- Identify what you think is important in your context. It js all about your thinking. You may find gaps, unconscious assumptions and cuttoff points, which serve as a good investigation plan.
- Have your work challenged. What you have created in previous points, is just your understanding of the reality. Make it more fidel by talking to field (or component) experts.
- Test the model. Does it really help you to meet your goals? Is it accurate enough? Refine and improve it if not.