The different meanings of the word "CONFIGURATION"
Ever wondered why discussions about "configuration" often lead to confusion? The term carries vastly different meanings depending on the context. From configuring product variants to managing technical baselines (configuration management) or tuning software parameters. In this article, we untangle the confusion, explore its three main interpretations, and offer tips to ensure clarity in your projects. Ready to decode "configuration"?
GENERALMETHODSFEATURED
Julian Weyer
cōn-fīgere (latin)
fasten/nail together, construct
Who hasn't experienced this in everyday project work? You're sitting in a meeting, talking and discussing, getting nowhere but not really knowing why. You get the feeling that you're talking past each other. There can be many reasons for this, but one hot contender is a lack of common understanding of terms.
One of these terms is the word configuration, which can have very different meanings depending on the context:
Configuration as in configuration management
Configuration in the sense of parameterisation
To add to the confusion: sometimes you have to deal with all three meanings at the same time in a project or process, and they are also somehow interrelated. But more on that later.
Origin of the word configuration
The prefix con- stands for ‘together’ in Latin. And figere, you guessed it, stands for ‘to join’, ‘to fasten’, 'to construct'. A ‘figure’ is therefore nothing other than something ‘joined’ or 'constructed' 😉. And a configuration is therefore something ‘joined together’, or more precisely, the process of joining.
In a configuration, I combine individual components to form something larger. And viewed from a distance, this is also true for all three interpretations.
CONFIGURATION
Color
Rollers
Arm rests
[ ] Black
[ ] Gray
[X] Turquoise
[ ] Without
[X] Standard
[ ] Adjustable
[X] For carpets
[ ] For smooth floors
#1
as in „variant configuration“
Again, a look in the dictionary will help: Latin variare means ‘to make colourful’, ‘to alternate colours’, ‘to colour’. The variant is therefore a certain ‘colouring’ of my product or the colouring of a component of my product. And this is exactly what variant configuration is all about: I (e.g. as a customer) combine individually ‘coloured’ components (variants) to create a product (combination = configuration).
Want an example? I configure a bicycle variant. I would like the frame in the ‘colouring’ trekking men's bike, 54cm. Colouring is of course not to be understood literally here, what is meant is the frame variant. Then a 21-speed version of the gears, the gel saddle and the whole thing in navy blue (this time the colouring is literal).
Voilà, we have put together one (of many many possible) bike variants from individual variants of the components - in other words, ‘configured’ 👍.
Strictly speaking, in my opinion, in many cases we should actually be talking about variant selection rather than configuration. But that's another topic, which I will certainly write about in the future 😉.
Example
CONFIGURATION
#2
e.g. according ISO 10007
as in „configuration management“
Anyone using the search engine of their choice will find various definitions (e.g. ISO 10007 or ANSI/EIA-649). Here, for example, according to ANSI:
"Configuration management (CM) is a management process for establishing and maintaining consistency of a product's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life."
I like the ANSI definition a lot because it contains important statements:
It is a management process
It ensures that the product conforms to its requirements
... and all this over the entire product life cycle.
Whatever standard you use as a basis, it fundamentally always works like this:
if we are responsible for a product, we must first determine which ‘elements’ are important to us (so-called configuration items). The term ‘element’ can and should be broadly understood, i.e. we not only look at the physical components (parts) of a product, but also at all information that is important in the context of development (and the entire lifecycle).
In other words, requirements, drawings, specifications, etc.
Identifying these relevant configuration items is then aptly called configuration identification in normative terminology. The configuration is the set of configuration items that we have identified as a result of configuration identification.
Configuration identification and configuration items
Here is an example - admittedly anachronistic and not very digitalised, but it's all about the principle:
Ingo, a senior engineer at a bicycle manufacturer, has to develop a new bicycle. In order to have proper configuration management, he (or his apprentice Anton) first creates a binder with various tabs that could be there:
Requirements
ISO 4210 (standard for bicycle design)
Requirements from sales (what do customers want)
Specification
Frame
Brake system
Drive/gear system
Production documents
Frame welding drawing
Assembly instructions
This completes the configuration identification and sets up the configuration. The relevant information that is currently valid is now filed peu-à-peu in the individual register sections of the binder.
The ISO 4210 register therefore contains ISO 4210:2023, the current version of the standard for bicycle design. A little later, as soon as the responsible designers have finished their work, the design drawings for the frame, brakes, etc. are also added.
In between, Anton (the apprentice) is tasked with photocopying the entire binder once a week and placing it in the archive (i.e. creating a snapshot).
At the latest when the development has been completed and the lead engineer Ingo has approved the maturity level of the specification, the photocopied folder is labelled ‘Design approved’ (AS-DESIGNED baseline) in bold red felt-tip pen.
Example
CONFIGURATION
#3
Connect to WiFi
SSID: JUWYs_WiFi
Localization
Language: english
Units: metric
Timezone: Pacific
Water hardness
°aH: 1
Machine configuration
as „parameterization“
of a smart product
Setting your favourite background in the Windows operating system, adapting the CAD system to the needs of your own company or entering the wheel size in the bike computer so that the speed can be displayed correctly. Colloquially, all of this also falls under the term ‘configure’. To bring it back into the context of the origin of the word ‘configuration’: you could say that you put together the individual switches and levers that the product offers you.
Perhaps a better term than configuration at this point is parameterization. My (software) product offers me various switches and setting options, for each of which I can set a parameter. In the case of the bicycle (computer), it is even a product consisting of SW and electromechanical components. Anyone who has a lot to do with Linux will be familiar with the *.conf files (like Configuration), and some may remember the .ini files under Windows. But the principle is always the same. The behaviour of the software or product can be influenced by setting switches.
Parameterization
All three meanings 'configured' together
In the previous sections, we learnt that the word ‘configuration’ can be used in very different contexts. In the introduction, I wrote that the three contexts can also occur together in a project or process to confuse everyone. As promised, a few words on this too.
A final example
Right from the start, Viktor from the sales department made a request to engineer Ingo that the bike should be available with a frame for women and one for men, as well as in different frame sizes. Three different brake disc sizes should be available, and the customer should be able to choose between 21 and 27 gears. And voilà, the configuration item ‘frame’ within the configuration as in configuration management is itself subject to a (variant) configuration 😉
As a result, of course, there are different (=variant) design drawings for the different frames, and therefore also different part and material numbers for how these different frames are identified in the logistics process.
If the bike manufacturer takes it very precisely, he will have the apprentice Anton make a new photocopy of the binder as part of configuration management and label it AS-ORDERED by Julian Weyer, right after I have ordered my bike. In this baseline, everything I have ordered (trekking men's bike, 54cm, gel saddle, 21-speed gears, navy blue, remember) will be marked with a highlighter, all variants that I have not ordered will be crossed or removed from the binder (whether I will ever get to see this photocopy of the binder myself is another matter, but it's just for the sake of principle).
The individual parameters (colloquially also the configuration) of the bike computer can also be configuration items in the sense of configuration management. This means that before the bike is delivered, the mechanic who assembled and parameterised it staples the parameter data into my photocopied file folder so that it is always possible to trace the condition in which I received my bike (AS-DELIVERED).
Sounds complicated and confusing? Actually, I find it all quite logical and coherent - if you are aware of these different aspects and correctly categorise the project context in each case. If in doubt, it's better to ask once more:
💬 What exactly do you mean when you refer to configuration?