Concept of Configuration
Configuration is the current actual state of the system (the realization of the system: all parts at all system levels) and its descriptions in accordance with them. Typically, during various projects, a multitude of different versions of system parts, various system descriptions, and their parts related to different moments in time are generated by various people, and it is necessary to understand which of all these parts of the system are included in the current system breakdown and which descriptions are relevant to them. Not all manufactured parts of the future system are used, some remain unused. Not all versions of system descriptions are implemented: some are rejected in favor of others that are suitable for the system's success, providing systems that are more functional, more reliable, cheaper, faster to manufacture, etc. If you apply the firmware of a previous version to the model of a phone for the next version of the phone, there is no guarantee that it will work. Such configuration collisions should not occur; all versions should correspond to each other.
During the development of an engineering system, various versions of system descriptions are usually considered: usage models, system concepts, architectures, "works" (source codes and 3D models). And these descriptions are also changed several times after revisions, error corrections, and adding new features to the system being described. How do you determine which versions of these descriptions should be used by manufacturers for the system's realization? And if some manufacturers change the realization of the system so that it no longer corresponds to these descriptions, and some manufacturers work "as agreed" — can you be sure that a functioning system can be assembled from the manufactured parts? Of course, not. Errors related to some parts of the system and their descriptions not being known, or even if known, not matching each other, are quite common - these errors are called configuration collisions (in engineering slang, a configuration with such errors is called a "broken configuration," which is a very unpleasant situation).
The configuration of the system consists of the system's parts and their descriptions. The configuration itself can be defined and, accordingly, documented. Configuration documentation (configuration description, sometimes also referred to as "configuration documentation") is often shortened in speech to just "configuration" - and the difference between the configuration (the composition of the system itself) and the documentation of the configuration must be determined from the context, just as the difference between architecture and architectural documentation when the word "architecture" is used for both.
Configuration management is the tracking of whether the configuration of the system realization and the system descriptions are known and correspond to each other. This discipline lies between managerial and applied engineering disciplines. The configuration is composed of configuration items - the smallest parts into which the system is divided in terms of its logistics. This concerns the units for transferring parts of the system and descriptions of these parts from one work performer to another, from one process to another.
Engineers of the target system often have more detailed descriptions of the system's parts than are required for organizing the movement of work products. For example, each of the billions of transistors on a chip is unique, but in the electronics workshop, the chip itself serves as a configuration unit and not these transistors separately, as the transistors are not transferred individually to anyone.
In order not to lose these configuration units in accounting, to be able to refer to them in conversation and in various system descriptions, they are given individual designations. The standard IEC 81346[1] represents a standard that proposes a typical way of such description, taking into account a systems approach - the presence of multiple alternative structures of the system (functional, modular/product, locations, cost-related, etc.).
System documentation is always documentation of some configuration items, and their designations are usually created by adding a description type to the name of the configuration item. If there is suddenly a need to describe three or four configuration items for some purpose, this most likely refers to describing a system from these items and it is simply necessary to create a new configuration item from them, to which the description will correspond.
A version of the system is its configuration as of a certain moment in time. Tracking the change of versions due to changes is necessary in order to clearly indicate which of the numerous configurations of the system that arise and disappear during the project is meant.
A baseline (baseline, configuration baseline) is a confirmed for integrity and administratively approved version.
Change management is often included in configuration management. They wrote: "configuration and change management," but usually this is a separate discipline. It should not be confused with managing organizational changes - how to change the organization in a way that does not cause resistance from people and leads to positive results. Engineering change management is about making decisions on configuration changes to minimize configuration errors. For this purpose, the configuration distinguishes between 1. regular working versions with simpler changes and 2. baselines, where making changes involves additional engineering and administrative checks for configuration integrity.